Ответ atlantidu в «Про норму работы для инженера»2
Поделюсь немного опытом планирования разработки для проектов. Сам работаю программистом уже более 10 лет.
На начальных этапах проекта ПМ работает с ведущим программистом и даже возможно с дизайнерами. Все они вместе работают с заказчиком.
Целью начального этапа является выяснение конкретных требований от заказчика. Требования эти могут меняться в процессе их обсуждения.
Результатом этого этапа становится какое то подобие дизайн документа, в котором описаны:
1. Проблема\задача, которую заказчик хочет решить
2. Решение этой задачи и пояснения, почему это решение заказчику подходит
3. Решение, разбитое на этапы. Каждый этап имеет свое описание, назначение, ответствнного и срок выполнения
При этом все должны понимать, что эти сроки только приблизительные. Точность сроков зависит от опыта ПМа и ведущего программиста.
После этого начинается детальная работа с требованиями и архитектурой, результатом чего является более детальные описания того, что нужно сделать и как. По сути ТЗ.
Имея ТЗ уже делается более тщательное планирование. Выбираются ключвые задачи для построения минимального продукта (MVP). По сути, тут уже, имея задачи и оценив эти задачи с командой, можно идти к закачику и озвучивать что либо, но только по MVP.
Я уже как то пытался этот процесс описать тут https://ru.stackoverflow.com/a/1137835/179763 и тут https://ru.stackoverflow.com/a/1012399/179763 - с точки зрения программиста.
Исходя из того, что выше сказано, ПМ по сути просто не имеет возможности выбирать самостоятельно какие части приложения будут выполнены, а какие нет. Это явно должно быть обговорено с заказчиком и ведущим программистом и зафиксировано в документах.
ПМ, по сути, отвечает за организацию такого процесса. Ведущий программист отвечает за техническую часть. Сроки обсуждаются, но у ведущего последнее слово. Если, к примеру, ведущий не согласен со сроками, он это должен явно озвучить ПМу и зафиксировать в документах.
Если ПМ вдуг по своему наитию идет к заказчику и о чем то договаривается, что не было обсуждено с командой или не было зафиксировано в документах - это уже вопросы к ПМу.
Задавать вопросы начальству не только можно, это обязательно надо делать. Если программситу что то не понятно или он с чем то не согласен, он дожен это явно высказать. Если программист не понимает задачу или не понимает зачем такая задача поставлена - он не должен даже начинать рабоать над задачей.
Если программст боится что то спросить или уточнить и вместо этого молча мучается, то это уже хреновый программист, он мало того, что неполезным делом занимается, но даже еще и затягивает сроки. Поэтому я приучаю программистов к тому, что все в проекте или по крайней мере в задаче должно быть ясно. Сама постановка задачи также должна быть предельно понятной.
В таком случае, если к вам вдруг приходит Начальник и спрашивает о сроках, то
1. Если вы ПМ, то у вас есть документ со сроками
2. Если вы ведущий, то шлете начальника а ПМу
Если в сроки вы не укладываетесь, то это должно означать, что
1. Вы не успеваете сделать MVP, а MVP - это малая часть проекта, то есть о проблемах со сроками вы узнаете как можно раньше. Это не катастрофа, вы можете обсудить это с ПМом и пересмотреть сроки и пойти с этим к заказчику.
2. Если сроки затягиваются уже после MVP - это не страшно, основной функционал уже все равно готов, вы можете с ПМом и заказчиком обсудить и либо сдвинуть сроки, либо уменьшить количество запланированного функционала.
Весь смысл этого - это fail fast подход, вы должны узнать о проблеме, если она имеется, как можно скорее и принять меры.
Если после такой работы заказчиком, документами, описаниями и прочим у вас возникает какая то катастрофа, требующая внимания начальника - у вас вероятно проблемы с процессом. Если к вам на каждой работе подходят начальники с одими и теми же претензиями, попробуйте найти проблему в себе.
Лига программистов
2K постов11.8K подписчиков
Правила сообщества
- Будьте взаимовежливы, аргументируйте критику
- Приветствуются любые посты по тематике программирования
- Если ваш пост содержит ссылки на внешние ресурсы - он должен быть самодостаточным. Вариации на тему "далее читайте в моей телеге" будут удаляться из сообщества