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

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

Как же быть?

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

Два варианта:

1. Сроки вычисляете вы (нужны навыки, среднестатистический девелопер этого не умеет).
2. Сроки вычисляет менеджер.

Если менеджер некомпетентен, как в вашем случае, то работать с таким человеком и тем более что то ему доказывать — себя не уважать.

Вам не нужно чтобы менеджер соглашался. Он выполнил свою работу — назвал срок. Делаете в своем привычном темпе. Если результат не совпадает с его прогнозами — то либо вы ничего не делали, либо он не компетентен и не умеет прогнозировать сроки разработки. Проводите разбор полетов, если нужно, и находите в чем проблема (в вашем случае менеджерит левый чувак, который думает что государством/проектом может управлять и кухарка)

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

Вообще, точные сроки (день в день, час в час, не раньше ни позже) мало кто способен вычислить. От этого и необходимость проектировать и обсуждать.
В статье представлен крайний случай, чтобы не рассусоливать «вы понимаете, что точно в сроки успеть не сможете и будет задержка в 2 дня». Это бы увеличило публикацию в 1,5 раза. В принципе, такая манера изложения была выбрана на пробу. Какие есть комментарии по этому поводу?
НЛО прилетело и опубликовало эту надпись здесь
Конкретику планирую описать в следующей статье. Если тема интересна.
Проектирование, декомпозицию и роль UML во всем этом разврате, на мой взгляд, очень доходчиво и на конкретных примерах описывает Крэг Ларман.
Книга 2004 года. Все еще актуальна?
Вполне. Сам язык не так сильно изменился, чтобы это как-то мешало (всё равно им серьезно никто не пользуется), а изложенные в ней принципы (agile-scrum, проектирование в целом) известны минимум лет 25 уже. Но модными стали только не так давно.
Спасибо, Александр. Добавлю в статью
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории