Как-то раз я принимал у подрядчика этап по контракту на разработку ПО. Вернее, там даже предпроект ещё был, без разработки. Сумма что-то вроде 4 млн.руб. Дело было пару лет назад, тогда была GPT-3.5.
И вот, с той стороны мне приезжает пачка документов. Цели проекта, архитектурная концепция, верхнеуровневый дизайн, этапность.
Сначала я начал всё это читать. Довольно быстро заподозрил неладное, пошёл к аналитику на сторону исполнителя. "Что за дерьмо ты мне прислал, брат?" Но в ответ он только хлопал глазами. Цели проекта есть? Есть. Концепция есть? Есть. Этапность есть? Есть. Чего не устраивает тогда?
Потом, как того требовали контрактные обязательства, я писал обоснованное возражение на всю ту дичь.
В результате конечно же этап приняли, но я тогда сильно задолбался. Так что простите, некоторое право быть токсичным имею.
Классический сценарий: нужен устав проекта для презентации спонсору. Раньше я писал его в Word, структурировал, согласовывал. 4 часа минимум.
А что если все ценное для потребителя Устава как артефакта как раз и ограничивается указанным в промпте:
ПРОЕКТ: Развёртывание сети киосков самообслуживания (КСО) в магазинах
МАСШТАБ: 30 магазинов, 120 КСО
БЮДЖЕТ: ~15 млн рублей
СРОКИ: январь-июнь 2026
А вся остальная обвязка, на которую вы раньше тратили по 3,5 часа (а теперь для её появления GPU греют атмосферу по вашему повелению), лишь затрудняет восприятие и пожирает драгоценное время спонсора?
ИМХО, тут автор попытался максимально обобщить продуктово-проектную тематику на любые области (не обязательно ИТ). В то время как delivery - это порождение в большей степени ИТ-проектного управления.
В последние ~5+ лет этим словом в программной разработке именуют всё, что с той или иной степенью допущения можно отнести к проектному управлению (релиз-менеджменту, как частному случаю), процессному управлению, формированию культуры (агиле-коучинг).
Я кстати затрудняюсь точно сказать, откуда именно этот термин проник в такое широкое употребление. Очевидные кандидаты - Service Delivery в ITIL. Ну и в канбане есть одноимённая роль service delivery manager'а.
Объединить проекты и продукты в программу с общими целями.
Не особо канонично, зато жизненно.
Классически полагается, что программы в компании запускаются от стратегических целей, а уже дальше декомпозируются на продукты, проекты по их созданию и вот это вот всё. Скажем прямо, до такого уровня зрелости удаётся дорасти не в каждой отрасли и не каждой экономической ситуации.
Гораздо чаще случается, что компания растёт, обрастает проектами и продуктами. А потом кому-то приходит в голову оценить оверхед, возникающий из того, что куча команд/подразделений делает примерно одно и то же. И тогда-то возникают различные инициативы по синхронизации, оптимизации и т.д. Объединение проектов в программы - один из вариантов поведения в этой ситуации, не единственный.
Получается, при проектировании новой фичи архитектор смотрит на схемы, описывающие текущую реализацию, и отображает новую целевую архитектуру где-то в сторонке. Потом, после разработки, деплоя и генерации модели изменённой архитектуры, можно сравнить то, что получилось, с тем, как это изначально видел архитектор. Верно?
Что-то, видимо, за прошедшие часы в DO изменилось. Только что пробовал привязать: виртуальную Visa Yoomoney, кредитку MC Tinkoff, виртуальную Visa Сбера, кредитку Альфы, дебетовую Visa Сбера. Все отклонены. Пичаль.
У меня есть человек, работавший на средне-высокой позиции в продуктовом маркетинге М.Видео. Сбежал при первой удобной возможности, ибо непрозрачность, кумовство и приоритет выслуги лет над реальными скиллами. Дело было пару лет назад.
Договорились просто: CPO с нами внутри "могучей кучки", активно участвовал в формировании целей, разделяет их, а также участвует в их достижении (ибо некоторая часть непосредственно в вотчине CPO и подчинённых ему PO, которые в командах).
Трудно сказать точно. Например, у меня это процентов 30-40, но на то я и манагер. У остальных точно меньше. У тех, кто в разработке очень глубоко, не больше 10%. Спросим на следующей ретре :)
Овертаймы управленцев мы, опять же, специально не считаем (в отличие от команд, там мы за овертаймами следим и возвращаем отгулами). По себе могу сказать, что в последнее время их не особо много, но были периоды, когда за неделю могло часов по 8-10 накапливаться.
Точно не временный. Но это не значит, что нас в какой-то момент не накроет озарение и мы не придумаем, как его улучшить/углубить/переиграть.
Оцениваем мы сами, глядя на доску с целями и на то, какие из них получают красные и зелёные ярлычки. Мы сами их себе придумали (никто к нам с палкой не приходил и не заставлял), сами же и заинтересованы в результате фактическом, а не для галочки.
По-разному оносится. Понятно, что результат нашей деятельности выливается в какие-то изменения в процессах, подходах и т.д. Кто-то к таким изменениям открыт, для кого-то они - суета и морока. Мы довольно много внимания уделяем тому, чтобы эти изменения не просто сверху спускать, а объяснять, для чего они и какому благу служат (пусть даже иногда и ценой каких-то потерь или дискомфорта на старте). Чаще получается, чем нет. Ну и здесь, кстати, тоже очень большую роль играет, что МНГ - это командная работа. На каждую проблему мы смотрим с разных сторон пятью парами глаз. Откровенная дичь, которая навредит или точно не зайдёт командам, просто отсеивается.
Какие-то в "серой зоне", но проявив некоторую инициативность, их можно перевести в первую группу.
Какие-то либо вне нашего контроля в принципе, либо можно их взять под контроль, но цена вопроса (величина той самой инициативности) такова, что дешевле забить.
Когда мы выписывали цели, не везде чётко понимали, сколько той самой инициативности по разным целям может понадобиться. В итоге, кое-что всё-таки в третьей группе осталось (например, очеловечивание бюрократических взаимодействий с материнской компанией). И мы честно себе признались, что "не в этот раз". В основном это что-то, что не слишком заметно для разработки в повседневной жизни.
Если честно, то статьи есть (по архитектуре и кейсам внедрения). Но написаны они были 1) много раньше, чем начались описанные здесь события, 2) с корп. аккаунта компании, от которой мы уже отделились. Поэтому в контексте этой статьи не очень правильно будет на них ссылаться. Свежего пока ничего не написали, к сожалению.
Ну и отдельно напомню, что пятеро, о которых речь в статье, это не дармоеды, которые ни фига не делают, только о высоком рассуждают :-) Чистых управленцев там полтора человека, остальные довольно-таки глубоко в жизни команд.
Пусть будет по-вашему.
Как-то раз я принимал у подрядчика этап по контракту на разработку ПО. Вернее, там даже предпроект ещё был, без разработки. Сумма что-то вроде 4 млн.руб. Дело было пару лет назад, тогда была GPT-3.5.
И вот, с той стороны мне приезжает пачка документов. Цели проекта, архитектурная концепция, верхнеуровневый дизайн, этапность.
Сначала я начал всё это читать. Довольно быстро заподозрил неладное, пошёл к аналитику на сторону исполнителя. "Что за дерьмо ты мне прислал, брат?" Но в ответ он только хлопал глазами. Цели проекта есть? Есть. Концепция есть? Есть. Этапность есть? Есть. Чего не устраивает тогда?
Потом, как того требовали контрактные обязательства, я писал обоснованное возражение на всю ту дичь.
В результате конечно же этап приняли, но я тогда сильно задолбался. Так что простите, некоторое право быть токсичным имею.
А что если все ценное для потребителя Устава как артефакта как раз и ограничивается указанным в промпте:
А вся остальная обвязка, на которую вы раньше тратили по 3,5 часа (а теперь для её появления GPU греют атмосферу по вашему повелению), лишь затрудняет восприятие и пожирает драгоценное время спонсора?
ИМХО, тут автор попытался максимально обобщить продуктово-проектную тематику на любые области (не обязательно ИТ). В то время как delivery - это порождение в большей степени ИТ-проектного управления.
В последние ~5+ лет этим словом в программной разработке именуют всё, что с той или иной степенью допущения можно отнести к проектному управлению (релиз-менеджменту, как частному случаю), процессному управлению, формированию культуры (агиле-коучинг).
Я кстати затрудняюсь точно сказать, откуда именно этот термин проник в такое широкое употребление. Очевидные кандидаты - Service Delivery в ITIL. Ну и в канбане есть одноимённая роль service delivery manager'а.
Не особо канонично, зато жизненно.
Классически полагается, что программы в компании запускаются от стратегических целей, а уже дальше декомпозируются на продукты, проекты по их созданию и вот это вот всё. Скажем прямо, до такого уровня зрелости удаётся дорасти не в каждой отрасли и не каждой экономической ситуации.
Гораздо чаще случается, что компания растёт, обрастает проектами и продуктами. А потом кому-то приходит в голову оценить оверхед, возникающий из того, что куча команд/подразделений делает примерно одно и то же. И тогда-то возникают различные инициативы по синхронизации, оптимизации и т.д. Объединение проектов в программы - один из вариантов поведения в этой ситуации, не единственный.
Спасибо за статью!
Получается, при проектировании новой фичи архитектор смотрит на схемы, описывающие текущую реализацию, и отображает новую целевую архитектуру где-то в сторонке. Потом, после разработки, деплоя и генерации модели изменённой архитектуры, можно сравнить то, что получилось, с тем, как это изначально видел архитектор. Верно?
Спасибо, добр человек.
В DO не получилось, а вот HostHatch - прошёл платёж с виртуальной Qiwi. Курс 129,1, ага.
Что-то, видимо, за прошедшие часы в DO изменилось.
Только что пробовал привязать: виртуальную Visa Yoomoney, кредитку MC Tinkoff, виртуальную Visa Сбера, кредитку Альфы, дебетовую Visa Сбера. Все отклонены.
Пичаль.
У меня есть человек, работавший на средне-высокой позиции в продуктовом маркетинге М.Видео. Сбежал при первой удобной возможности, ибо непрозрачность, кумовство и приоритет выслуги лет над реальными скиллами. Дело было пару лет назад.
В ИТ не так?
Договорились просто: CPO с нами внутри "могучей кучки", активно участвовал в формировании целей, разделяет их, а также участвует в их достижении (ибо некоторая часть непосредственно в вотчине CPO и подчинённых ему PO, которые в командах).
Трудно сказать точно. Например, у меня это процентов 30-40, но на то я и манагер. У остальных точно меньше. У тех, кто в разработке очень глубоко, не больше 10%. Спросим на следующей ретре :)
Овертаймы управленцев мы, опять же, специально не считаем (в отличие от команд, там мы за овертаймами следим и возвращаем отгулами). По себе могу сказать, что в последнее время их не особо много, но были периоды, когда за неделю могло часов по 8-10 накапливаться.
Точно не временный. Но это не значит, что нас в какой-то момент не накроет озарение и мы не придумаем, как его улучшить/углубить/переиграть.
Оцениваем мы сами, глядя на доску с целями и на то, какие из них получают красные и зелёные ярлычки. Мы сами их себе придумали (никто к нам с палкой не приходил и не заставлял), сами же и заинтересованы в результате фактическом, а не для галочки.
По-разному оносится. Понятно, что результат нашей деятельности выливается в какие-то изменения в процессах, подходах и т.д. Кто-то к таким изменениям открыт, для кого-то они - суета и морока. Мы довольно много внимания уделяем тому, чтобы эти изменения не просто сверху спускать, а объяснять, для чего они и какому благу служат (пусть даже иногда и ценой каких-то потерь или дискомфорта на старте). Чаще получается, чем нет. Ну и здесь, кстати, тоже очень большую роль играет, что МНГ - это командная работа. На каждую проблему мы смотрим с разных сторон пятью парами глаз. Откровенная дичь, которая навредит или точно не зайдёт командам, просто отсеивается.
Какие-то цели под нашим контролем полностью.
Какие-то в "серой зоне", но проявив некоторую инициативность, их можно перевести в первую группу.
Какие-то либо вне нашего контроля в принципе, либо можно их взять под контроль, но цена вопроса (величина той самой инициативности) такова, что дешевле забить.
Когда мы выписывали цели, не везде чётко понимали, сколько той самой инициативности по разным целям может понадобиться.
В итоге, кое-что всё-таки в третьей группе осталось (например, очеловечивание бюрократических взаимодействий с материнской компанией). И мы честно себе признались, что "не в этот раз".
В основном это что-то, что не слишком заметно для разработки в повседневной жизни.
Если честно, то статьи есть (по архитектуре и кейсам внедрения).
Но написаны они были 1) много раньше, чем начались описанные здесь события, 2) с корп. аккаунта компании, от которой мы уже отделились.
Поэтому в контексте этой статьи не очень правильно будет на них ссылаться.
Свежего пока ничего не написали, к сожалению.
Ну и отдельно напомню, что пятеро, о которых речь в статье, это не дармоеды, которые ни фига не делают, только о высоком рассуждают :-) Чистых управленцев там полтора человека, остальные довольно-таки глубоко в жизни команд.