Недавно поймал себя на забавной мысли
Когда-то мне казалось, что проекты проваливаются из-за сложных технологий
ну там: плохая архитектура, интеграции, сервера и прочая айтишная мистика 😅
А потом прошло лет десять
И оказалось, что большинство проектов ломаются о гораздо более скучные вещи:
- 💚Никто не договорился о сроках
- 💚Нет человека, который реально принимает решение
- 💚Требования существуют в формате «ну вы же понимаете»
- 💚Пользователей забыли предупредить
- 💚Тестирование сделали по принципу «вроде работает»
Хотя в начале все выглядело очень амбициозно 🙂
За свою карьеру я реализовал больше 50 проектов
Продуктами, которые мы запускали, пользуются миллионы людей
Снаружи это обычно выглядит красиво 🙂
А вот внутри шишек было достаточно )))))
И в какой-то момент я начал собирать для себя простой чек-лист:
Сохраняй себе 👇
- 📌 Заказчик
Он должен существовать
Конкретный человек, который скажет:
«да, это мой проект, я сформулирую что мне надо и дам ресурсы» - 📌 ИИ - только по делу
Если задача решается Excel, регламентом или парой SQL-запросов - не тащи туда ИИ ради красивой презентации - 📌 Финансовый эффект
До старта посчитай:
что изменится, сколько времени/денег будет экономиться или зарабатываться
Все «ну потом как-нибудь посчитаем» я теперь стараюсь воспринимать очень осторожно 🙂 - 📌 Требования
Сначала попроси описать что нужно. Хотя бы крупными мазками.
Потом планируй проект
И да, заказчик почти всегда сам не до конца понимает чего хочет.
Это нормально - 📌 Срок
Пусть даже примерный
Проект без срока начинает жить своей жизнью 🙂
Как ремонт у знакомых, который идет третий год - Почти все эти проблемы были вообще не про технологии 🙂
- 📌 ТЗ
Без него разработка начинает напоминать ремонт на кухне у родственников:
«Раз уж вскрыли стену, давайте еще вот это сразу сделаем» 😅 - 📌 Стейкхолдеры
Люди намного спокойнее принимают изменения,
когда с ними поговорили заранее, а не поставили перед фактом - 📌 Тестирование
Проси показать план тестирования
И обязательно смотри, под какой ролью проходят сценарии
Половина сюрпризов обычно живет именно там 🙂 - 📌 Ролевая модель
Кто что может делать в системе
Лучше договориться об этом до разработки, а не после первого скандала - 📌 Контуры разработки
Хотя бы два
А лучше четыре:
разработка, интеграции, приемка, прод
Иначе прод очень быстро превращается в тестовый стенд 😬 - 📌 Работа с пользователями
Самое опасное время проекта -
первые дни после запуска
когда команда уже морально “закрыла задачу”, а пользователи только начали страдать 😅
Фраза:
мы уже разбираемся
обычно снижает уровень паники лучше половины технических решений - 📌 Обратная связь
После релизов собирай комментарии, метрики, баги
Люди намного спокойнее относятся к ошибкам, когда видят, что их слышат - 📌 Деньги
Условия вознаграждения лучше обсуждать заранее
И про премию команде за успешный запуск тоже забывать не стоит
Сейчас понимаю, что зрелость руководителя часто проявляется не в том,
как он героически тушит пожар 🔥
А в том,
сколько пожаров вообще не случилось благодаря скучной подготовке 🙂
Если тебе есть что добавить — пиши в комментариях
И пусть этот чек-лист будет для тебя как ремень безопасности:
кажется скучной формальностью ровно до первого серьезного столкновения 🙂
#Инструменты
#УправлениеПродуктами
Дискуссия