Как стать автором
Обновить

Комментарии 3

Ошибка №0 - доверчивость. Не то, что менеджера пытаются обмануть, но:

  • Разработчики могут сильно ошибаться в оценках. Мелкие задачи переоцениваются, большие недооцениваются.

  • Могут сказать, что что-то сделать не возможно.

  • Могут сказать, что "ну вот без этого рефакторинга на пару месяцев - никак".

  • Могут уходить влево от своей задачи.

  • Могутне считать спеки.

  • Могут не так понять задачу и сделать что совершенно другое (см. предыдущий пункт)

  • Бывают пессимисты, оптимисты, паникёры и весь набор других характеров, который может "за апудрить мозги" нетехническому менеджеру.

  • Простую задачу делать долго прокрастинируя, или занимаясь чем-то сторонним.

    Что делать?

  • Жёстко приоритизировать спринт, чтобы самые важные задания были обязательно сделаны.

  • Собирать мнения больше, чем от одного разработчика или Тим Лида, если есть малейшие сомнения, и когда вы слышите - "это сделать нельзя", "о.. ну это займёт месяц работы" на казалось бы не такую сложную работу.

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

  • Запретить сарказм и другие проявления неконструктивного диалога.

  • Мотивировать.

Спасибо за статью! Взял некоторые пункты на вооружение :)

Интересная статья и полученные опытным путем выводы о необходимости: оценки задач всей командой, регулярного демо стейкхолдеру, обязательной ретроспективы с командой, участия команды в уточнении бэклога... Хорошие практики. Что-то напоминают... Кажется это scrum?

Но статья хорошая :)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий