Когда проект делается плохо
Сделать плохой проект в моей области деятельности легко. Достаточно отправить требования от клиента разработчику и сказать "делай". При этом или игнорируя, или сильно идя на поводу клиента в вопросах, в которых разработчик говорит, что так "плохо". Все, больше никаких транзакций. (а зачем, ведь у менеджера еще есть другие проекты, между которыми надо разрываться и тратить силы)
Что в таком случае происходит? Разработчик первое время, имея какой-то запас энергии, старается что-то сделать "правильно". Со временем эта энергия из-за происходящего "тупизма" (в конце проекта менять ключевой аспект системы, потому что так захотелось, например) исчезает, а источников ее пополнения нет. В итоге получается, что клиента говорит, менеджер транслирует (при этом стараясь думать на минимальном уровне), а разработчик делает со словами "как сказали, так и сделал" (ни шага вправо или влево, ни инициативы).
В итоге имеется некачественный продукт, который затем еще и поддерживать (я сейчас не буду говорить про внешнюю составляющую проекта, только про внутреннюю "кухню"). Итого компания теряет деньги на всех этапах: на этапе производства на некачественном функционале, реализуемом чаще всего за бортом спланированного, на этапе поддержки на всплывающих недочетах этапа реализации.
Причины могут быть такие:
- менеджер заинтересован только в том, чтобы уложиться в план, "сдать" и получить бонусы, на все проблемы просто мотает головой и не комментирует
- разработчик работает положенные 8 часов, ибо все остальное ему не компенсируется, отсутствие мотивации влечет к потере качества
- клиент, который говорит "хочу", считая себя гуру во всем, игнорируя объективность
- выше стоящее руководство, которое все пустило на самотек, полагая, что там сами справятся
- внешние обращения, не связанные с проектом, но отвлекающие всех участников проекта
- слабая нервная система людей
- полное отсутствие общей технологической концепции, участие разных людей, неведующих "предысторию"
Решения:
- адекватный менеджер, который прежде всего заинтересован, пусть даже ему не хватает знаний и опыта
- адекватное отношение к разработчикам, которые не являются "скотом", которому корм бросил и забыл, а есть люди, которые хотят делать что-то нужное, "правильное", и быть за это вознагражденными
- попытаться уладить отношение с клиентом, а точнее человек, который сможет убеждать человека на той стороне в том, что правильно, а что нет, чтобы не идти на поводу всегда
- адекватное управление не только в рамках этого проекта, но и смежных
- грамотное управление внутренней структурой проекта, выделение одного ведущего специалиста, который разбирается в "технике", который бы смог помочь менеджеру в вопросах, в которых тот не ведает
Ну и вообще, одна сильная, харизматичная личность в проекте (раз уж вертикаль власти отсутствует) способна решить все проблемы и объединить людей!
Что в таком случае происходит? Разработчик первое время, имея какой-то запас энергии, старается что-то сделать "правильно". Со временем эта энергия из-за происходящего "тупизма" (в конце проекта менять ключевой аспект системы, потому что так захотелось, например) исчезает, а источников ее пополнения нет. В итоге получается, что клиента говорит, менеджер транслирует (при этом стараясь думать на минимальном уровне), а разработчик делает со словами "как сказали, так и сделал" (ни шага вправо или влево, ни инициативы).
В итоге имеется некачественный продукт, который затем еще и поддерживать (я сейчас не буду говорить про внешнюю составляющую проекта, только про внутреннюю "кухню"). Итого компания теряет деньги на всех этапах: на этапе производства на некачественном функционале, реализуемом чаще всего за бортом спланированного, на этапе поддержки на всплывающих недочетах этапа реализации.
Причины могут быть такие:
- менеджер заинтересован только в том, чтобы уложиться в план, "сдать" и получить бонусы, на все проблемы просто мотает головой и не комментирует
- разработчик работает положенные 8 часов, ибо все остальное ему не компенсируется, отсутствие мотивации влечет к потере качества
- клиент, который говорит "хочу", считая себя гуру во всем, игнорируя объективность
- выше стоящее руководство, которое все пустило на самотек, полагая, что там сами справятся
- внешние обращения, не связанные с проектом, но отвлекающие всех участников проекта
- слабая нервная система людей
- полное отсутствие общей технологической концепции, участие разных людей, неведующих "предысторию"
Решения:
- адекватный менеджер, который прежде всего заинтересован, пусть даже ему не хватает знаний и опыта
- адекватное отношение к разработчикам, которые не являются "скотом", которому корм бросил и забыл, а есть люди, которые хотят делать что-то нужное, "правильное", и быть за это вознагражденными
- попытаться уладить отношение с клиентом, а точнее человек, который сможет убеждать человека на той стороне в том, что правильно, а что нет, чтобы не идти на поводу всегда
- адекватное управление не только в рамках этого проекта, но и смежных
- грамотное управление внутренней структурой проекта, выделение одного ведущего специалиста, который разбирается в "технике", который бы смог помочь менеджеру в вопросах, в которых тот не ведает
Ну и вообще, одна сильная, харизматичная личность в проекте (раз уж вертикаль власти отсутствует) способна решить все проблемы и объединить людей!