PM & AI

Я столкнулся с тем, что мы каждые полгода наступаем на одни и те же грабли. Не потому что команда глупая или невнимательная, а потому что знания уходят вместе с людьми или просто тонут в море документов. В последнее время меня беспокоил один парадокс: мы тщательно фиксируем риски, пишем post-mortem, сохраняем артефакты, но в новом проекте всё равно действуем так, будто опыта у нас нет. Недавно я решил провести эксперимент: вместо того чтобы в очередной раз «собрать волю в кулак» и заставить команду перечитывать старые репозитории, я отдал этот архив нейросети и спросил: «Что мы обычно забываем?»...

Я всегда немного кривился, когда слышал фразу «Устав проекта — это священный документ». В моей практике он чаще был «священной коровой», которую мы долго и больно заполняли в начале, чтобы потом положить на полку и никогда не открывать. Классический парадокс инициации: пока согласуешь цели и границы с заказчиком и внутренними стейкхолдерами, проект уже должен быть на середине. В последнее время меня беспокоила мысль: а не пытаемся ли мы автоматизировать молотком то, что требует микроскопа? С предыдущими экспериментами (оценка сроков, фасилитация, управление рисками) ИИ справлялся неплохо, но там была аналитика...

В последнее время меня стал преследовать один и тот же сценарий. Приходит в проект новый разработчик, чаще всего джун или мидл. Первую неделю он героически пытается вникнуть в архитектуру, задаёт много вопросов. А потом начинается самое утомительное: он подходит к тимлиду (он же у нас почти ведущий разработчик) и спрашивает: «А почему вот этот микросервис общается с БД напрямую, минуя основной бэкенд?». Сеньор отрывается от своей задачи, лезет в схему, начинает объяснять контекст и историю принятия того или иного архитектурного решения. Через час он возвращается к своему коду, но контекст уже потерян...

В последнее время меня стал преследовать один и тот же сценарий. Приходит в проект новый разработчик, чаще всего джун или мидл. Первую неделю он героически пытается вникнуть в архитектуру, задаёт много вопросов. А потом начинается самое утомительное: он подходит к тимлиду (он же у нас почти ведущий разработчик) и спрашивает: «А почему вот этот микросервис общается с БД напрямую, минуя основной бэкенд?». Сеньор отрывается от своей задачи, лезет в схему, начинает объяснять контекст и историю принятия того или иного архитектурного решения. Через час он возвращается к своему коду, но контекст уже потерян...

Недавно поймал себя на мысли, что наш процесс управления рисками превратился в формальность. У нас был реестр, мы его вели, раз в месяц на проектном комитете пробегали глазами по списку: «А, этот риск уже не актуален, этот мы митигировали, ну а этот... ну, как-нибудь». Знакомая ситуация? В какой-то момент перестаешь замечать очевидные угрозы, потому что они становятся частью твоей реальности. Ты привыкаешь к тому, что «фронтендер вечно болеет», а «аналитик перегружен». Это кажется данностью, но по факту — это риски, которые мы перестали таковыми считать. Мне пришла идея: а что, если дать нейросети...