Чеклист для ~больших~ средних проектов

На относительно больших веб-проектах часто встречаются проблемы в организации процесса. Поэтому я решил собрать моменты, на которые стоит обратить внимание, в единый список, с которым можно сверяться при оценке незнакомого проекта (или построении процесса с нуля).

Постановка задач

Сервер

Дизайн

Верстка

Бэкенд

Коммуникации

Все члены команды должны быть связаны со всеми остальными. Давно уже у всех есть доступ в интернет, есть Skype [http://www.skype.com/], есть TeamViewer [http://www.teamviewer.com/] (if you like it - buy it!). Сотрудник, который проверяет почту раз в неделю, а отвечает на нее еще реже (при этом, сотового у него нет, потому что он Перельман) - не очень хороший сотрудник (хоть и, возможно, отличный программист). Схема, при которой все общение между верстальщиками, программистами и дизайнерами идет только через менеджера - тоже не очень эффективна. Имеет смысл ограничить “прямую” постановку задач, но вопросы типа “как вот это у тебя должно работать” должны ходить напрямую.

Мы не успеваем!!!

Если проект не укладывается в сроки или в бюджет - команда об этом должна узнать как можно раньше. Чтобы вместо “релиза” глючного, постоянно падающего и частично вообще нефункционального нечта можно было заранее обсудить сроки, урезать функциональность (почти всегда оказывается, что можно урезать что-то ресурсоемкое, но маловажное для пользователя) и выкатить рабочий продукт.

Собственно, это одна из мантр agile - постоянно иметь рабочий продукт. После первой недельной итерации мы должны иметь рабочий продукт. Да, он мало что умеет, но он работает, он не падает, и его всегда можно показать при возникновении вопроса “а чем вы тут так долго занимаетесь?”.

Методология

Лучшая методология разработки ПО [http://xn—–clcksaplxf6byd3cyb.xn–p1ai/]

А если человек много треплется, но мало двигает дело вперед - ну его нафиг.

У нас не сработает

Если в команде мало людей (нет денег, злой заказчик и т.п.), указанные выше роли можно распределять по нескольку на одного человека. От чего-то можно отказаться совсем (например, не делать графический дизайн, а взять готовую тему для фреймворка, или вместо найма программистов взять cms), важно только осознавать “за” и “против”.

comments powered by Disqus