Когда проект делается плохо



Сделать плохой проект в моей области деятельности легко. Достаточно отправить требования от клиента разработчику и сказать «делай». При этом или игнорируя, или сильно идя на поводу клиента в вопросах, в которых разработчик говорит, что так «плохо». Все, больше никаких транзакций. (а зачем, ведь у менеджера еще есть другие проекты, между которыми надо разрываться и тратить силы)

Что в таком случае происходит? Разработчик первое время, имея какой-то запас энергии, старается что-то сделать «правильно». Со временем эта энергия из-за происходящего «тупизма» (в конце проекта менять ключевой аспект системы, потому что так захотелось, например) исчезает, а источников ее пополнения нет. В итоге получается, что клиента говорит, менеджер транслирует (при этом стараясь думать на минимальном уровне), а разработчик делает со словами «как сказали, так и сделал» (ни шага вправо или влево, ни инициативы).

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

Причины могут быть такие:
— менеджер заинтересован только в том, чтобы уложиться в план, «сдать» и получить бонусы, на все проблемы просто мотает головой и не комментирует
— разработчик работает положенные 8 часов, ибо все остальное ему не компенсируется, отсутствие мотивации влечет к потере качества
— клиент, который говорит «хочу», считая себя гуру во всем, игнорируя объективность
— выше стоящее руководство, которое все пустило на самотек, полагая, что там сами справятся
— внешние обращения, не связанные с проектом, но отвлекающие всех участников проекта
— слабая нервная система людей
— полное отсутствие общей технологической концепции, участие разных людей, неведующих «предысторию»

Решения:
— адекватный менеджер, который прежде всего заинтересован, пусть даже ему не хватает знаний и опыта
— адекватное отношение к разработчикам, которые не являются «скотом», которому корм бросил и забыл, а есть люди, которые хотят делать что-то нужное, «правильное», и быть за это вознагражденными
— попытаться уладить отношение с клиентом, а точнее человек, который сможет убеждать человека на той стороне в том, что правильно, а что нет, чтобы не идти на поводу всегда
— адекватное управление не только в рамках этого проекта, но и смежных
— грамотное управление внутренней структурой проекта, выделение одного ведущего специалиста, который разбирается в «технике», который бы смог помочь менеджеру в вопросах, в которых тот не ведает

Ну и вообще, одна сильная, харизматичная личность в проекте (раз уж вертикаль власти отсутствует) способна решить все проблемы и объединить людей!