Входная точка в проект
Недавно с коллегами на работе делали стандартизацию ведения проектов разного размера: от одной команды на 3–6 месяцев до нескольких команд на пару-тройку лет.
Так вот, у нас внезапно случилась любопытная синергия, и получилось, что «хотели как лучше, а получилось еще лучше».
Что сделали?
Утвердили набор всяких стандартных вещей, которые по проекту надо вести.
Команда, смежники, заказчики, дедлайны, DoD, риски, майлстоуны, логи синхронизационных встреч с прогрессом, реестр важных обсужденных вопросов и принятых по ним решений, ADR и прочее такое, что в проектном менеджменте любят.
Правда некоторые управленцы, которые из инженерии пришли, да в ней и остаются, занимаясь больше ей, а не управлением, наоборот не любят, ибо «опять бюрократию развели». Но чтобы никого не обижать, всю эту развесистую «бюрократию» в сложном мультикомандном проекте берет на себя технический проджект. Работа такая, всё нормально.
Почему получилось еще лучше?
Так как сразу несколько типов артефактов создаются и ведутся в разных инструментах, то логично было завести единую входную точку, эдакую сводную страницу со всеми ссылками на то, где доки, схемы, задачи, логи встреч и т. д.
И вот оказалось, что если всё это хозяйство добросовестно вести + иметь ИИ, немного обмазанный MCP для доступа к нужным системам, то можно, опираясь на эту входную точку в проект, творить за считанные минуты чудеса, на которые раньше уходили бы часы.
От простого сбора статуса состояния проекта до сложного анализа, где на чьей стороне буксует, где разъехались или противоречат друг другу требования, кто систематически продалбывает обещания, как можно наложить на этот конкретный проект с его контекстом инструменты из разных методик типа теории ограничений или ТРИЗ.
Короче, прям очень много информации можно добыть, сгенерить, провалидировать. Понятное дело, что доверяй, но проверяй, однако лично мне на своих проектах очень нравится, как идет. Но я пока еще только осваиваюсь, поэтому просто поделился впечатлениями и рабочей базовой идеей.
Итог
Если покрутить мой канал лет на 5–6 назад, то уже тогда можно было заметить, что я всегда выступал за порядок ведения дел, написание документации и инструкций. И вот с такой агентизацией как будто бы это одна из тех вещей, где сейчас рады те, у кого этот порядок был, и грустят те, у кого «ой-ёй, мой агент выдает фигню, потому что он научился на неактуальной документации пятилетней давности, что же делать?».
Это как я был сторонником удаленки еще с 2015 года, старался разбираться, как правильно организовать работу в распределенной команде, и в 2020-м году моя команда разошлась на локдаун и стала перформить не хуже, чем раньше.
А те, кто считал, что надо для эффективной работы обязательно ходить в офис и постоянно друг к другу подходить, дергать за рукав и рисовать на салфетке вместо генерации нормального артефакта, в 2020-м резко взгрустнули, их работа сильно замедлилась на долгие месяцы (трустори).
Недавно с коллегами на работе делали стандартизацию ведения проектов разного размера: от одной команды на 3–6 месяцев до нескольких команд на пару-тройку лет.
Так вот, у нас внезапно случилась любопытная синергия, и получилось, что «хотели как лучше, а получилось еще лучше».
Что сделали?
Утвердили набор всяких стандартных вещей, которые по проекту надо вести.
Команда, смежники, заказчики, дедлайны, DoD, риски, майлстоуны, логи синхронизационных встреч с прогрессом, реестр важных обсужденных вопросов и принятых по ним решений, ADR и прочее такое, что в проектном менеджменте любят.
Правда некоторые управленцы, которые из инженерии пришли, да в ней и остаются, занимаясь больше ей, а не управлением, наоборот не любят, ибо «опять бюрократию развели». Но чтобы никого не обижать, всю эту развесистую «бюрократию» в сложном мультикомандном проекте берет на себя технический проджект. Работа такая, всё нормально.
Почему получилось еще лучше?
Так как сразу несколько типов артефактов создаются и ведутся в разных инструментах, то логично было завести единую входную точку, эдакую сводную страницу со всеми ссылками на то, где доки, схемы, задачи, логи встреч и т. д.
И вот оказалось, что если всё это хозяйство добросовестно вести + иметь ИИ, немного обмазанный MCP для доступа к нужным системам, то можно, опираясь на эту входную точку в проект, творить за считанные минуты чудеса, на которые раньше уходили бы часы.
От простого сбора статуса состояния проекта до сложного анализа, где на чьей стороне буксует, где разъехались или противоречат друг другу требования, кто систематически продалбывает обещания, как можно наложить на этот конкретный проект с его контекстом инструменты из разных методик типа теории ограничений или ТРИЗ.
Короче, прям очень много информации можно добыть, сгенерить, провалидировать. Понятное дело, что доверяй, но проверяй, однако лично мне на своих проектах очень нравится, как идет. Но я пока еще только осваиваюсь, поэтому просто поделился впечатлениями и рабочей базовой идеей.
Итог
Если покрутить мой канал лет на 5–6 назад, то уже тогда можно было заметить, что я всегда выступал за порядок ведения дел, написание документации и инструкций. И вот с такой агентизацией как будто бы это одна из тех вещей, где сейчас рады те, у кого этот порядок был, и грустят те, у кого «ой-ёй, мой агент выдает фигню, потому что он научился на неактуальной документации пятилетней давности, что же делать?».
Это как я был сторонником удаленки еще с 2015 года, старался разбираться, как правильно организовать работу в распределенной команде, и в 2020-м году моя команда разошлась на локдаун и стала перформить не хуже, чем раньше.
А те, кто считал, что надо для эффективной работы обязательно ходить в офис и постоянно друг к другу подходить, дергать за рукав и рисовать на салфетке вместо генерации нормального артефакта, в 2020-м резко взгрустнули, их работа сильно замедлилась на долгие месяцы (трустори).