Доля проекту залежить від безлічі факторів, включаючи людський.
А цей фактор, як відомо, дуже нестабільний, так давайте не будемо його провокувати зайвий раз і будемо слідувати наступним радам…

Відношення менеджера до проекту

Менеджер не повинен висловлювати своє ставлення до проекту аля “проект повна ж…” (ППЖ) – таким чином він заздалегідь налаштовує розробника на провал…

Ставлення колег до проекту

Бачачи що вашому колезі дістався проект з розряду ППЖ, не варто висловлювати йому своє співчуття словами “Проект тобі дістався – ППЖ” – це не тільки погіршить Ваші з ним відносини (слова “Тобі б такий” може і не будуть сказані, але на мові точно будуть крутитися), але і може нашкодити самому проекту…

Архітектура проекту

На розробку архітектури часто приділяється мало часу, і дуже даремно. Необхідно привчити розробника спочатку продумати архітектуру до останнього гвинтика, а лише потім писати код. А у нас, найчастіше, “шашки наголо” і давай махати, нарубали дров, заспокоїлися і почали переписувати весь код заново – але бюджет проекту не гумовий – і це треба пам’ятати не тільки менеджеру проекту, але і розробникам.

І нема чого винити реалізацію, якщо архітектуру про…ли.

Дизайн проекту

Краще коли дизайн є з першого дня розробки, і тому є кілька причин:

  • програмісту не хочеться займатися рутиною – а сірі форми підштовхують до думки про те, що це “черговий проект” (а якщо попередній закінчився провалом – явно буде негативний настрій на роботу)
  • чим дельше в ліс – тим складніше буде прикрутити дизайн

Але дизайн – дизайну ворожнечу – він може стати дратівливим чинником на весь час розробки, так що якщо зроблений дизайн не подобається нам, не варто його показувати замовнику з надією – авось прокотить…

І ще процитую Стіва Джобса: “У промові більшості людей “дизайн” означає облицювання, але це зовсім не так. Дизайн — це основа і душа будь-якого людського творіння” – так давайте запам’ятаємо це, і не будемо створювати проекти-зомбі…