Как не сделать ИТ-продукт за девять месяцев: вредные советы от Product Owner
Статья будет в первую очередь интересна тем, кто уже прошёл через ряд подобных сложностей при создании продукта. А также тем, кто подобных сложностей стремится избежать.
Статья будет в первую очередь интересна тем, кто уже прошёл через ряд подобных сложностей при создании продукта. А также тем, кто подобных сложностей стремится избежать.
Не совсем понимаю ваш треугольник "Срок, Бюджет, Результат". Первые два понятия вполне измеримы, а чем измерять Результат - не ясно. Возможно вы имели ввиду классический "Cost Time Quality triangle", так как качество ещё можно условно измерить.
Совет "Определяйте и гоните сроки без оснований" не верный, так как важнее всего именно продукт, а не его код. Иногда важнее давать жёсткий (но адекватный) дедлайн свыше, чем постоянно спрашивать команду о сроке. Дедлайн даёт понимание всем участникам команды, что этот тот финиш, к которому надо придти, и если идти не получается, то иногда надо и бежать (работа в выходные или овертайм). И по моему опыту - когда команда прошла через тяжёлый дедлайн, но всё успела в самый последний срок и с должным качеством, то это только сплачивает людей.
Ну и про "Если происходит факап - то провал тоже общий" - это хорошо звучит на бумаге и публичных выступлениях, но в жизни если аналитик накосячил с постановкой, то ни девелоперы, ни тестировщики не будут считать себя виноватыми. Сложно считать себя виноватым, если ты старался по максимуму и из-за другого человека вы облажались. Поддержка и командный дух - это важно, но ожидать что люди разделяют косяки друг друга немного наивно.
Уточню первый абзац - Вы об этом классическом треугольнике? https://en.wikipedia.org/wiki/Project_management_triangle
Спасибо за комментарий! @Игорь Беляк показал в ссылке ту версию треугольника, что я имел ввиду. Результат = скоуп, в данном случае. Прошу прощения за неточность, обычно оперирую такими терминами - вопросов не вызывало пока :)
Про сроки. Если дедлайн адекватный - согласен полностью. Как же часто бывало в моей практике - срок прилетает "сверху", где бизнес определяет, что вот эта маленькая функциональность - дело двух дней работы джуна. А по факту за ней стоит рефакторинг системы). Утрирую конечно, но я думаю, что мысль донес.
Поэтому все задачи от бизнеса я стараюсь провести через тех-ревью (хотя бы поверхностное). В сжатых сроках ничего смертельного нет, а вот в невыполнимых (неадекватных) умирает мотивация, особенно если успеть все же не удалось, как ни гнали. Бывали, конечно же (намного реже), и позитивные моменты - когда успевали несмотря ни на что и это объединяло.
Здесь соглашусь лишь отчасти. Все же, работы над проектом очень завязаны с друг-другом. Это происходит как в последовательном сообщении, так и на этапе работы определенного специалиста - когда ему требуются уточнения, консультации. Если брать и делать бездумно по задаче - то часто и получается, что "ну ты же накосячил, я просто задачу делал". Я всегда стараюсь обсуждать задачи, получать обратную связь и сводить людей для обсуждения. И получается так, что бэкэнщик вроде как участвует в работе дизайнера, а тестировщик - в работе фронта. Конечно, это может быть моей локальной прихотью, я не 20 лет в разработке. Но думаю, что любой продукт - это люди, в первую очередь.