Pull to refresh

Архитектор — лучший друг продакта

System Analysis and DesignDesigning and refactoringProduct Management

Суть статьи очень простая - архитектор представитель бизнеса в разработке. Его амбассадор. Проводник мысли продакт-менеджера во все укромные уголки проекта. Продакту нужно дружить с архитектором. Быть с ним на одной волне. Только так он сможет получить ожидаемый результат.

Эта статья для тех продактов, которые этого еще не понимают. Я постарался изложить ее на продактском языке в форме диалога. Максимально кратко. Потому, что продакты не любят много буковочек.

Самозарождение архитектора

Начнем с простого. Продакт, скажи, есть ли у тебя архитектор в проекте? Если есть, можешь пропустить этот раздел. Ты уже явно получил пару важных жизненных уроков и сделал верные выводы. Но если нет, то давай разбираться.

Ты работаешь по модным правилам SCRUM? Твой проект команда? Ведь скрам это именно про команду. Нет скрама без команды. Значит тебе знакомы этапы командообразования. Напомню:

Эти этапы проходит любая команда. Так вот, одним из важных результатом этапа “бурление” становится распределение ролей в команде. Берем за аксиому, что если команда не сбалансирована по ролям, то она ущербна в эффективности. Но ты же #янетакой? Твоя команда - огонь! Так вот…

Есть такая роль в команде по Белбину “Генератор идей/мыслитель”. Его функции описываются так:

Предлагает оригинальные идеи. Решает сложные вопросы.

Т.е. хочешь ты этого или нет, а человек, который будет эту роль тянуть появится. Самозародится.

Архитектура как элемент стратегического планирования

Скажи, продакт, ты показывал своему архитектору canvas продукта? Показывал? Вы все обсудили и учли в соответствующих разделах его важные замечания? Тогда ты явно получил большой жизненный опыт. Смело иди к следующему разделу. Но если нет, то тебе будет интересно узнать, что…

Архитектор это человек с системным мышлением. Кормить его бизнес-требованиями, это как показывать фотографии кадров фильма в асинхронном порядке. Не понимая сути сюжета он соберет из кадров свой сюжет. Поверь, ты будешь удивлен его креативностью.

Только понимая как продукт решает проблемы клиента, архитектор сможет предложить приемлемые технологии, которые минимально повлияют на затраты. Более того, скорее всего он тебе накинет умных идей как еще можно решить проблемы клиента.

Как только ты разделишь со своим архитектором canvas, вы войдете с ним в “дрифт” по технологии “Егерей”. С этого момента ты можешь быть спокоен. Твой птичий язык будет понятен с получирика. Ты сэкономишь уйму времени на постановку ТЗ, разъяснения, почему зеленые кнопки на синем фоне это важнее реляционной модели хранения данных. Твой мир уже не будет прежним. Он будет наполнен розовыми пони и радугой.

Теперь ты понимаешь, почему архитектор должен быть обязательной частью стратегической сессии?

Архитектура и этапы развития продукта

Давай вспомним этапы развития продукта:

Очевидно, что на стадии внедрения на рынок, продукт существует за счет инвестиций. Привлечь их сложно. Велик соблазн как-то минимизировать риски на этом этапе. И что ты делаешь? MVP! Хитрый ход хитрого продакта! Из г..на и палок собрать что-то и посмотреть реакцию рынка.

Что ты говоришь команде при разработке MVP?

Вы должны понимать, мы исследуем гипотезу. Не факт, что продукт взлетит. У нас ограничены ресурсы. Нужно делать как можно быстрее и дешевле. Потом закроем технический долг.

Твои слова? Теперь смотри, ты сделал продукт из легкодоступных материалов. И внезапно он взлетает. По закону развития продукта нужно переходить на этап роста. А ты не можешь. Не можешь потому, что в твою команду набраны молодые, подающие надежду разработчики, которые еще вчера учились в online школе питона. И даже больше сотни клиентов в день твой продукт не держит. Твои действия?

Новые инвестиции под успешные показатели продукта? Но мы то знаем, что у тебя команда не готова для новых высот. Она, конечно, получила ценный опыт сделав тебе MVP. Но этот опыт ценен только для них самих. Результат их работы с вероятностью 99% это необъятный океан легаси кода на который ты не сможешь завезти нормальных спецов. Тех спецов, которые тебе теперь нужны как воздух, чтобы занять самую сладкую долю открывшегося рынка. Маркетинг говорит - вон там много вкусного! А ты такой - погодите, у нас тут цепь на велике спала.

Продакт, ты же помнишь, что рынок не терпит пустоты? Даже если тебе удалось найти нишу, и так сложилось, что у тебя нет конкурентов, то у тебя точно есть субституты.

Завидя твои успехи, имея опыт и ресурсы, они могут очень быстро воспользоваться твоим опытом. Пока вы дружной командой натягиваете цепь на твой новый велик, злобные конкуренты быстренько запилят все то же, но с моторчиком. Назовут это мопедом. Потому, что копирование успешного продукта на свободном рынке это наиболее успешная и дешевая стратегия. Под нее и инвестиции можно получить легко. Уж точно легче чем ты получал. И вот ты уже в унылой ж...

Так что же делать? Ответ очевидный - верить в успех. Твой архитектор и команда должны соответствовать амбициям продукта. Делай MVP. Но не экономь на нем.

Если не уверен, значит не провел достаточных исследований. Не заполнил тот самый canvas. Не поговорил со своим архитектором. Не согласовал с ним этапы развития продукта. И у вас не родилась поэтапная целевая архитектура. Архитектура, готовая к развитию продукта. Архитектура, дарящая тебе радость каждого дня.

Архитектура и этапы развития компании

Редкий продакт долетит до этапа стабильности в своем проекте. Но если ты #янетакой, ты должен понимать как все будет дальше. После MVP.

После MVP (возможная смерть в младенчестве) твоя команда обязана трансформироваться. Она станет костяком новой, успешной компании. К тебе придут люди, которые нужны скорее тебе, чем ты им. Ну как придут, ты их будешь почти “умолять” прийти именно к тебе. Потому, что у тебя пока нет корпоративной культуры и бренда. В лучшем случае базовые потребности закрыты.

И тебе нужно будет их онбордить. Как? Мыкоманда? Там стул, там кофе и печенки? Но вы уже не команда. Да, страстный запил MVP при должном подходе действительно создает команду. Но спускаемые задачи в толпу, это уже не команда. Тебе все сложнее и сложнее добиваться замысленного результата. Основной проблемой становится - коммуникации.

Ты конечно борешься… ты же самый, самый, самый! Организуешь кучу встреч, всех отвлекаешь, достаешь всякой лабудой типа кучи митапов, стендапов, фасилитаторов и скраммастеров.

Но на самом деле, ты просто надежно сидишь в ловушке основателя.

Ловушке основателя - термин означает высокую зависимость компании от ее основателя, который замыкает на себе все процессы в компании, но сам не в состоянии выделить время на анализ и решение всех задач.

И тут, внезапно, тебе на помощь опять мчится архитектор на белом единороге! Этот зануда, оказывается, напилил еще на MVP кучу понятной и нужной документации по архитектуре системы. И когда к тебе приходит новый сотрудник, который должен через 3 часа сдать первую фичу на горячий прод, только архитектор скажет - Сынок, не ссы, я тебе помогу!

И вот оно чудо! Ты пошел заниматься своими важными бизнес-делами, а онбординг в систему ложится на сильные плечи твоего архитектора. И не нужны твои митапы по 20 раз на дню, т.к. все и так при деле.

И вот она - “Юность”! Тебе нужно делить компанию на подразделения, стримы и т.п. гордо вступая в этап “расцвет”. Как ты думаешь, сможешь ты одновременно заниматься этим и развитием бизнеса? Вот и я думаю, что нет. Наберешь директоров? А что они понимают в твоем основном активе - системе? Ты думаешь они будут твоей золотой пилюлькой?

Возможно ты удивишься, но первое что сделают твои новые лощеные директора - побегут искать хоть кого-то кто хоть что-то в этой шляпе понимает. Ведь систему распиливать это вам не KPI внедрять. И тут… ну ты понял.

Заключение

Как мы выяснили, архитектор штука важная и нужная. Хорошая новость - он есть всегда. Но с ним нужно уметь работать. Плохая новость - как любую роль, роль архитектора может занимать “не тот человек”. Нужно найти “того человека”.

Архитектор в продукте это не должность. Крайне важно это отметить. Это человек берущий на себя важнейшую роль. Фактически, он может быть ведущим разработчиком, аналитиком, CTO и т.д. Но вполне логично выделять эту роль явно. Ожидая от него совершенно конкретных результатов.

P.S.

Лично я считаю основной проблемой современного тренда на стартапы продактов-суицидников. Это люди, которые на самом деле не верят в жизнь после MVP. Ровно по этой причине для них нет смысла вкладываться в систему. Они не проводят анализа продукта, не умеют выявить реальные потребности клиента и их удовлетворить. Их продукт обречен на смерть.

Но я уверен, что это не про тебя, мой дорогой продакт!

Tags:архитектураархитекторпродакт-менеджментпродактпродукт
Hubs: System Analysis and Design Designing and refactoring Product Management
Total votes 13: ↑8 and ↓5 +3
Views1.7K
Senior Software Developer (KTM project)
from 230,000 to 250,000 ₽KOFAXСанкт-ПетербургRemote job
Business Intelligence Analyst (Reporting and Visualization) (BI)
to 4,500 €ExnessЛимассолRemote job
Business System Analyst (Payment Systems CY)
from 3,000 to 4,000 €GA TechЛимассолRemote job
Backend Engineer
from 2,400 $VideolyRemote job