Возвращаюсь к вам со списком уроков, которые я извлек из проектов внутренней автоматизации.
◻️ В условиях жестких сроков нельзя стартовать проект, если:
- Не определен лидер мнений в команде разработчиков
- Не назначена роль того, кто будет принимать ключевые волевые решения внутри всей команды
- Отсутствует DoR (Definition Of Ready) = критерии готовности постановки задачи для разработки. Это позволило бы сразу определить границу в части взаимных ожиданий «аналитик не написал, или не увидели очевидное разработчики и тестировщики»
◻️ Не тратить время на ревью ТЗ силами команды, если команда не готова
◻️ Готовить данные для прода со старта проекта, так как это оказалось сложно, нервно и повлияло на состав ТЗ и проектных решений, так как не все «задуманные» данные нашлись - под конец проекта неожиданно выявилось, что у нас нет части справочных данных, а на экране уже были предусмотрены колонки в таблице под их отображение. Как итог ни данных, ни экономии драгоценного свободного места на экране, потому что просто не успели.
◻️ Не спешить принимать решения, если команда разработки настаивает на упрощении ТЗ, чтобы «успеть» в сроки.
Стоит брать паузу, а далее соотносить предлагаемые изменения на цели бизнеса и требования пользователей - проще это делать при наличии трассировки требований.
◻️ В условиях разработки «супер-MVP» необходим план организационных и технических мероприятий на случай ошибок.
Например, дополнительные БД-конверсии (миграции данных), в том числе откатные. Или конкретные фразы для отработки возражений пользователей или потенциального «неприятия» новой системы.
◻️ Не смешивать роли.
В моей истории
я был единственным аналитиком проекта и ключевым пользователем новой системы. Подобное провоцирует риски:
🟣 Искажения восприятия системы - она может казаться простой и удобной с точки зрения пользователя под влиянием того, что вы автор ТЗ и проектных решений.
🟣 Подмены требований определенного класса пользователей - «мне точно нужно, а значит и другим подойдет». Другими словами, неосознанно можно сделать себя ключевой персоной.
Как не допустить:
🟢 давать солировать
другим пользователям-источникам требований, соответствующим вашей бизнес-роли
🟢 при сомнениях доносить до них идеи и согласовывать. Не думать в этот момент о том, как это повлияет на ТЗ и дизайн системы.
◻️ Эскалировать, если ЗЛ не вовлекаются в проект или думают, что у них останется опция не переходить на новую систему 😄
◻️ Не надеяться на то, что кто-то сделает «ничейную» работу.
Предлагать самостоятельно план действий и вписывать туда ответственных, если выделенной роли проектного менеджера не предусмотрено.
