Правила прожект-менеджмента

[andrzejn]

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

Уроки, которые мы извлекли из поражения, общеизвестны, но повторить их не помешает:

• Не начинать дизайнить архитектуру и интерфейс, пока нет чётких спецификаций и понимания предметной области.
• Обо всём непонятном в требованиях и предметной области спрашивать заказчиков, а не пытаться догадаться самим.
• Дизайнить попроще, не закладывая чересчур сложных и обобщённых решений "на вырост".
• Не начинать писать код, пока дизайн архитектуры не готов.
• Стараться держать стабильныю команду разработчиков от начала до конца проекта. Добавлять/убирать разработчиков по одному-два и с перерывами, чтобы давать команде время стабилизироваться. Ядро команды вообще не отвлекать на другие проекты.
• Непрерывно, ежедневно следить за прогрессом каждого участника команды. Ошибки - исправлять, мотивации - раздавать, планы - корректировать.
• Следить, чтобы разработчики досконально разбирались в тонкостях своего участка работы, прежде чем начинать что-то кодировать.
• Разрабатывать не "вширь" (много новых фич одновременно), а "вглубь": сосредотачиваться на минимальном количестве фич, которые команда может делать одновременно, не мешая друг другу, но уж эти фичи прорабатывать до конца, и только потом переходить к следующим.
• Выпускать промежуточные релизы как можно чаще. Требовать от заказчиков просматривать изменения и давать обратную связь.
• Когда время поджимает, сбрасывать лишние фичи, а не стараться всё успеть за нереальный срок.

Comments

[gds.livejournal.com]

я говорю про средний случай. Далеко от идеала, ясен перчик. Попрошу всех откомментировать -- интересно, ить.

> Не начинать дизайнить архитектуру и интерфейс, пока нет чётких спецификаций и понимания предметной области.

Обычно чётких спецификаций никогда нет. Повезёт, если есть правильный аналитик. Если не повезёт -- проекту будет трудно.

> Обо всём непонятном в требованиях и предметной области спрашивать заказчиков, а не пытаться догадаться самим.

С последним согласен, но вот на вопросы о непонятном чаще отвечают "иди ты на" либо что-то невнятное, непристойное и неприменимое к дизайну.

> Не начинать писать код, пока дизайн архитектуры не готов.

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

> Разрабатывать не "вширь" (много новых фич одновременно), а "вглубь": сосредотачиваться на минимальном количестве фич, которые команда может делать одновременно, не мешая друг другу, но уж эти фичи прорабатывать до конца, и только потом переходить к следующим.

а Вы вот лично что хотите от Вашей работы? Вы любите деньги? А Ваши клиенты насколько похожи на типичного клиента microsoft?

> Следить, чтобы разработчики досконально разбирались в тонкостях своего участка работы, прежде чем начинать что-то кодировать.

попробуйте уследить за всеми, ага-ага.

> Выпускать промежуточные релизы как можно чаще. Требовать от заказчиков просматривать изменения и давать обратную связь.

из этого согласен только с требованиям обязать пользователя давать обратную связь. Первое неэффективно, второе нереально.

> Когда время поджимает, сбрасывать лишние фичи, а не стараться всё успеть за нереальный срок.

для бизнеса полезно выпустить полу-альфа-версию.
Вы разве не любите деньги?
А для души полезнее всё-таки делать так, чтобы нереальных сроков не было. Ненавижу работать тогда, когда это меня хоть чем-то раздражает.

[andrzejn]

Понятно, что рекомендации даны для идеального случая. В реальности что-то приходится нарушать. Чем больше нарушишь - тем больше вероятность провалить проект. В этом проваленном проекте мы нарушили их все.

Для моей работы он плох тем, что нужно все-таки сначала показать результат начальникам, которые будут весьма субъективно определять, нравится ли им всё это говно.

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

а Вы вот лично что хотите от Вашей работы? Вы любите деньги? А Ваши клиенты насколько похожи на типичного клиента microsoft?

Деньги я люблю. Но делать такие программы, в которых не придётся потом вечно исправлять баги, я люблю не меньше. Правильное сопровождение в моём понимании - это добавление и улучшение фич.

А с нынешними клиентами нам, в целом, повезло. Это таки типичные клиенты MS.

попробуйте уследить за всеми, ага-ага.

Когда подчинённых в пределах семи - я справляюсь. Правда, сам при этом уже ничего не программирую, не остаётся ни сил, ни времени.

> Выпускать промежуточные релизы как можно чаще. Требовать от заказчиков просматривать изменения и давать обратную связь.

из этого согласен только с требованиям обязать пользователя давать обратную связь. Первое неэффективно, второе нереально.

А на что же пользователь будет давать обратную связь, если не показывать ему свежие изменения? Выпускать релизы чаще, чем раз в неделю, действительно неэффективно. Но реже, чем один-два раза в месяц - опасно.

для бизнеса полезно выпустить полу-альфа-версию.
А для души полезнее всё-таки делать так, чтобы нереальных сроков не было.

Для бизнеса важно удовлетворить клиента. Дальше уже начинается специфика конкретных клиентов, кто в какой позе предпочитает...

А для души - согласен, дедлайны несовместимы с удовольствием от программирования.