Вступление
На своих проектах мне несколько раз приходилось совмещать роли менеджера проекта и аналитика.
С одной стороны, это научило меня разбираться в нюансах процессов бизнеса и разработки, грамотно планировать и контролировать сроки, фасилитировать встречи, задавать нужные вопросы и принимать оптимальные решения.
С другой, смешивать роли — не всегда самый лучший сценарий. Потому что из фокуса постоянно что-то выпадает, иногда не хватает времени и рук "на всё про всё".
И это влияет на качество результата.
Помимо этого такой расфокус ведет к выгоранию, что к слову со мной произошло на последнем месте работы.
Ускорило данное явление то, что я был также тимлидом и лидером команды. Но про это расскажу в другой раз.
Цель статьи: попытаться посмотреть на проект глазами аналитика и проджекта, найти точки соприкосновения этих двух ролей и дать вам пищу для самостоятельного ответа на вопрос: совмещение ролей аналитика и ПМ в одном проекте - это хорошо либо плохо?
Давайте для начала обозначим зоны ответственности аналитика и проектного менеджера.
Зоны ответственности аналитика
Если говорить общими словами, то аналитик связывает бизнес и команду разработки. Его основная обязанность — спроектировать цифровой продукт таким образом, чтобы задачи пользователя решались, цели бизнеса достигались, а интересы команды разработки и требования к системе и удобству были учтены.
P.S. В этой статье я сознательно буду использовать в примерах фулстек-аналитика, совмещающего роль системного и бизнес-аналитика.
Такой "гибрид" сейчас наиболее востребован на рынке.
Обязанности аналитика:
Проведение вторичных исследований рынка.
Анализ потребностей целевой аудитории.
Интервьюирование бизнеса для понимания целей и задач.
Проработка верхнеуровневой архитектуры продукта.
Проектирование бизнес-процесса разрабатываемой функциональности.
Проработка функциональных и нефункциональных требований к системе.
Подготовка необходимых диаграмм для команды разработки.
Передача материалов командам дизайна и разработки.
Проектирование спецификаций API.
Ответственность аналитика:
КАЧЕСТВО ТРЕБОВАНИЙ - извлечение, формализация, управление, передача требований;
КОММУНИКАЦИЯ - командная работа и отношение с клиентом;
ОЦЕНКА И СРОКИ - соблюдение установленных трудозатрат аналитики.
Зоны ответственности проектного менеджера
Проектный менеджер управляет процессами проектирования и разработки, устраняет узкие места и неэффективности.
Он же транслирует в команду ограничения со стороны бюджета и сроков и следит за тем, чтобы принимаемые решения учитывали эти ограничения. А ещё обеспечивает клиенту прозрачность хода проекта и результатов и свободное движение информации между всеми участниками.
Обязанности менеджера проекта:
Выбор подходящего фреймворка и адаптация производственного процесса под проект или команду.
Выявление основных метрик проекта и управление ими.
Повышение эффективности обмена информацией между участниками проекта, контроль за её систематизацией и тщательным сохранением.
Формулировка цели вместе с командой и бизнесом, фокусировка команды на целях.
Управление ожиданиями.
Управление проектными рисками.
Доведение всех задач проекта до результата.
Критический взгляд на всё и регулярная рефлексия.
Ответственность менеджера проекта:
РЕЗУЛЬТАТ - достижение целей проекта, разработанные решения проблем;
БЮДЖЕТ - соблюдение установленных рамок расходов;
СРОКИ - соблюдение графика времени.
Теперь, определившись с обязанностями и ответственностью каждой роли, поговорим про...
Взаимоотношения между аналитиком и менеджером проекта
В некоторых компаниях менеджеры проектов и аналитики переплетаются между собой не по должностным инструкциям, но по своим функциям.
Хотя это может сработать в некоторых небольших компаниях или продуктах, по мере роста компании и усложнения задач вероятность успеха этой совместной роли снижается, поскольку основные цели ролей различны.
При этом они не являются взаимоисключающими.
Обязанности аналитика и менеджера проекта различны, а это означает, что у них также разные ключевые интересы в проекте.
Аналитика можно считать наиболее заинтересованным в продукте (требованиях, бизнес-потребностях, результатах), тогда как менеджер проекта больше всего заинтересован в завершении проекта.
Например, аналитик может иметь глубокое понимание требований к функциям, которые, если их не реализовать, сделают решение недостаточно эффективным.
При этом менеджеру проекта может не хватать времени и/или ресурса, и он естественно предложит удалить эту "важную" функцию, чтобы пошустрее закрыть проект.
В данном случае интересы аналитика и руководителя проекта противоположны — им явно придется договариваться друг с другом.
В действительности, наиболее успешные менеджеры проектов и аналитики имеют крепкие отношения друг с другом, а это означает, что они понимают свою роль, свой вклад и чего ожидать от другой роли в совместной работе для достижения желаемых результатов.
Продолжим сравнивать роли аналитика и проджекта, но уже в разрезе фаз проекта.
Сравнение ролей аналитика и менеджера проекта
Любой проект состоит из нескольких этапов, таких как инициация, планирование, исполнение, контроль и завершающий этап.
Теперь давайте подробнее рассмотрим, каковы именно роли аналитика и менеджера проекта на этих этапах.
Инициация
Роль аналитика в процессе инициации заключается в общении с заинтересованными сторонами и сборе требований.
Между тем, роль менеджера проекта здесь заключается в том, чтобы сосредоточиться на финансировании и сроках. Это означает, что менеджер проекта собирает всю необходимую информацию о бюджете и доступном времени, чтобы он мог планировать ресурсы и соответствующим образом подготовить графики работы.
Планирование
Затем проект переходит на стадию Планирования.
На этом этапе аналитик более детально работает над бизнес- и функциональными требованиями. Он разбивает процесс и распределяет работу между разработчиками и даже другими аналитиками.
Менеджер проекта, с другой стороны, готовит план коммуникаций между командой и заинтересованными сторон, и также работает над планом управления рисками. Аналитик и менеджер проекта объединяют свои идеи и взгляды на задачи, а затем ПМ составляет roadmap проекта.
Исполнение
В процессе реализации аналитик тщательно оценивает проект. Принимая во внимание, что менеджер проекта несет ответственность за мониторинг проекта на этом этапе.
Оба профессионала заботятся о том, чтобы работа была выполнена в срок и без ошибок.
Естественно, аналитик тут выступает "руками" и активно участвует напрямую в фазе Исполнения и проявляет себя.
Контроль
Этап контроля предназначен для рассмотрения окончательных результатов и затем проведение демонстрации заказчикам.
Окончательный результат проверяется аналитиком, менеджер проекта завершает проект.
Заключительная фаза
На этом последнем этапе аналитик (если нет технического писателя) составляет финальную версию документации (включая руководство пользователя, сопровождения и пр.) и передает ее менеджеру проекта.
Итак, кажется, что мы действительно убеждаемся, что аналитик и проджект - как два сапога пара на проекте.
Но что будет, если один человек влезет в эту пару сапог и начнет вершить правосудие?
Ответ будет в финальном блоке статьи про...
Совмещение ролей аналитика и проджект менеджера
В современных IT-компаниях часто встречаются случаи совмещения ролей в команде. Это происходит не только в небольших компаниях, где очевидны ресурсные ограничения, но и в крупных.
Казалось бы естественным разделить роли в команде для повышения эффективности. Однако, потребность в анализе растет, и часто на проектах можно встретить специалиста, совмещающего аналитика и руководителя проекта. А в продуктовых компаниях такое совмещение перерастает в отдельную должность - Product owner.
На моем личном опыте я совмещал роль аналитика и проджекта в Сбере на проекте по сбору и обработке обратной связи по бета-версии Сбербанка Онлайн.
В проект меня бросили сначала как аналитика, и только потом выяснилось, что менеджерить этот проект некому..
Что в общем-то меня не остановило: всех заинтересованных собрал-поженил, составил и предложил им MVP, создал roadmap проекта, мне подыскали разраба, далее я с архитектором еще дополнительно прорабатывал решение, чтобы корректно легализоваться в ИТ-ландшафте Банка.. и мы успешно запустили MVP!
Если выделять основные причины совмещения ролей аналитика и проджекта, то вот они:
Финансы - сокращение финансовых расходов;
Операционное управление - задачи координируются быстрее;
Принятие решений - решения принимаются быстрее.
Бонусом можно выделить заимствование опыта и быстрый профессиональный рост специалиста, который в одних проектах совмещает роли, а в других исполняет их по отдельности: ты как аналитик перенимаешь опыт проджекта, и наоборот.
Вывод
Честно сказать - хочется, чтобы вывод вы сделали сами, господа.
Напишите ваше мнение в комментариях: совмещение роли аналитика и проджект менеджера на одном проекте - это хорошо или плохо?
Я же в рамках статьи:
посмотрел на проект глазами аналитика и проджекта
разделил их обязанности и ответственности..
и тут же предложил точки соприкосновения этих двух ролей
и не забыл поделиться своим успешным опытом (хотя успешный он был только в начале - выгорел я по итогу знатно)
Спасибо за прочтение!
Комментарии (22)
vmkazakoff
05.09.2023 18:53Все плохо. У вас был крайне неудачный опыт((
Роль аналитика совсем не подразумевает анализ рынка и потребностей. Это роль продакта (продакт менеджера) которую, так уж вышло, вы тоже на себя взвалили.
А проджект не выбирает фреймворк (это даже продакт не делает, это техлид, иногда это называется тимлид) и не контролирует метрики (это делает продакт).
Ну и уж точно обе роли совсем не про коммуникацию в команде. Не в том плане что люди с этой ролью не могут на себя брать такие задачи, а а том что роль от этого все равно не перестанет называться "скрам мастер" (ну или политрук или зампокадрам по старому)
Итого: в бедного вас ради экономии ставок впихнули 5 ролей: проджект, продакт, аналитик, тех(тим)лид и скрам-мастер.
Не скажу что так нельзя или это не встречается, но это точно не хорошо. Нормально если есть хотя бы три живых человека на эти роли. Т-шейп это замечательно, но тут уже не Т, а Ж-шейп.
Роль продакта: понимать что хочет бизнес и как это влияет на метрики. Видеть как это влияет на роадмап и бэклог. Отвечает за результат.
Роль бизнес-аналитика: переводить то что описал продакт на технический язык - документация, спецификация API, сущности и методы, передача этого всего дизайну и потом разработчикам.
Роль техлида: выбор фреймворков, библиотек, стэка (если это все уже не выбрано раньше) и остальных решений которые все эти задачи поддержат технически и не похоронят проект под ворохом зависимостей и ограничений.
Проджект контролирует сроки, бюджеты, согласует правки. Ходит за продактом пока не получит оценки дедлайнов.
Скрам-мастера (коуч) - следит за коммуникацией и процессами. Следит за обменом информации.
Нормально если на эти пять ролей есть трое. Ну минимум двое. Один продакт со скилами проджекта, второй техлид и аналитик, шарят скрам процессы. Или один аналитик и продакт а одном, второй техлид и скрам, шарят пополам проджектовую часть. Но когда все эти роли расписаны в одном человеке - это жесть. Я вам очень соболезную, и понимаю почему в статье общий посыл "так не надо".
Понятно что много задач эти ребята решают совместно и хорошо бы на некоторых встречах с бизнесом продакту быть вместе с аналитиком. Или на встречах типа PBR рулить процессами техлиду и аналитику одновременно. Но это не значит что впихнуть все в одного человека это нормально.
fenrrr Автор
05.09.2023 18:53Добрый день!
Ну во-первых, я не могу сказать, что опыт у меня был неудачный. В рамках своего плана развития внутри компании я очень хотел стать продактом. И реализуя этот проект я увидел возможность им стать через транзишн аналитик->менеджер проекта->менеджер продукта. Более того, мне даже прямо сказали про это. Но, увы, из Сбера я ушел по причинам, не связанным с работой, но с личной безопасностью.
Про анализ рынка - часто бывает такое, что этим занимается бизнес-аналитик, особенно на западе. Также этим могут заниматься и продуктовые аналитики. Ну и продакт менеджеры. И обратите внимание, я специально написал ВТОРИЧНЫЕ исследования.
Про фреймворк - когда команду подбираешь под проект, то ты как проджект должно определить, по какому фреймворку она должна работать, чтобы успешно закрыть проект. Про тех стек речи нет - естественно, это вне компетенций проджекта
Про коммуникации - я еще раз обращу внимание, что проджект менеджер - он про ПРОЕКТ. Продакт менеджер про КОМАНДУ. То, что вы упомянули скрам-мастер, это определенная РОЛЬ в КОМАНДЕ, которая работает по фреймворку Scrum. А мы говорим про проектную деятельность, в которую зачастую вовлечены несколько команд. Скрам-мастера в этом случае некорректно приплетать.
А про мнение касательно совмещения ролей - большое спасибо, что поделились!
chieftain_yu
05.09.2023 18:53Если проджект - про проект, а продакт - про команду, то про продукт-то кто? Тот самый аналитик?
fenrrr Автор
05.09.2023 18:53Привет! Спасибо за замечание - я не успел поправить комментарий, что продакт менеджер про ПРОДУКТ. Хабр не дал это сделать..
В обсуждении в моем канале уже успели этот момент разобрать.
Я человек ленивый, поэтому сделаю копипаст комментария Сергея Елизарова - ценнейшего человека в нашем коммьюнити:"напишу критику сюда: продакт это не про команду, продакт это про продукт — у него объект управления это продукт)
ему не надо думать о команде, ему надо думать о ценности продукта и достигает он ее или нет) и если нет — как ее достигать. а это сложная работа, и если совместить обе роли, то будет страдать одна из шапочек
про команду — это people manager, им может быть как продакт (что, на самом деле, по мне порочная практика, не видел хороших реализаций), но чаще — это тимлид/любой другой пипл менеджер. часто видел, что это ложится на проджекта (точнее, называют проджектом пипл менеджера)"
И также поделюсь мнением Сергея касательно идеальной комбинации команды.
Я данный сетап поддерживаю и с удовольствием в таком бы поработал:"самую идеальную комбинацию я видел, которая хорошо работает :
1. есть и проджект, который умеет головой отвечать за деньги, бюджетирование и использование ресурсов помимо разработки + вести переговоры + координировать кросс-функциональную команду
2. есть продакт по долгу службы (если это проекты поверх продукт) — он умеет вычленить, что нужно и как нужно, в каком приоритете и вляет на цели проекта так, чтобы это принесло пользу продукту в рамках стратегии
3. есть технический менеджер — он же пипл менеджер. он агрегирует кадровые риски, готовит команду и "спонсирует" людьми проект + отвечает за их кусок работы, организует процесс доставки ценности
4. ну и есть команда разработки с аналитиком, где аналитик уже вторичную валидацию проводит и доуточняет решение
из п.4 так-то можно вычленить аналитика, если у продакта достаточно ресурса, продакт лучше может описать что нужно, т.к. имеет больше контекста)"
Thebear
05.09.2023 18:53+2Скрам буклеты со мной не согласятся, но если ПМ не следит за коммуникацией это почти гарантирует проблемы.
Чем больше живу, тем больше убеждаюсь, что ПМ это не про таски в джире двигать и бюджет обновлять, а про то как следить за коммуникациями, проверять и перепроверять, что все на одной волне и знают зачем они делают то что делают и что у них есть всё что нужно для работы.
Captain_Jack
05.09.2023 18:53Под фреймфорком автор имел в виду не технический фреймворк, который для написания кода, а процессный - канбан например.
Captain_Jack
05.09.2023 18:53Роль системного аналитика не подразумевает анализ рынка, а роль бизнес-аналитика вполне себе. Автор пишет, что совмещал обе.
chieftain_yu
05.09.2023 18:53Анализ рынка (емкость, основные клиенты, маржинальность - все вот это) на крупных проектах - это работа продуктового аналитика - помощника продакта.
Еще в аналитика (помимо задач трех видов аналитиков, продакта, проджекта и срам-мастера) могут пытаться запихивать задачи маркетолога, пиарщика, тест-дизайнера и еще многих и многих специалистов.
Captain_Jack
05.09.2023 18:53+1Спасибо за статью, автор. Похоже её не так просто понять основной массе аудитории, средний разработчик или QA часто довольно смутно понимает, чем отличается проджект менеджер, продакт менеджер, бизнес-аналитик, системный аналитик, скрам-мастер, и причём здесь тимлид :)
Так что имхо мало кто сможет прямо нормально погрузиться в материал.
А по сути статьи - совместить БА и СА - это уже не очень просто, и эффективно так делать получится скорее на небольших проектах. Вы к этому добавили ещё сверху тимлида и проджекта, что вообще похоже на чудеса эквилибристики. Из моего опыта так можно жить только если команда состоит из 2 человек, а аналитика требуется по минимуму, и при этом заказчики и стейкхолдеры проекта - очень лояльные люди, и у них с вами и между собой отличная коммуникация. Во всех остальных случаях это путь в трэш и безумие :)
ValeryGL
05.09.2023 18:53Я работал в таком сетапе команды из двух человек: проджект-менеджер, занимающийся в недозагруженное время требованиями и проектированием, два разработчика и тестировщик. Плюсы - экономлю на коммуникациях, когда например внутренний РМ просит аналитика оценить сроки; минусы - отсутствие коллегиального мнения, например, в том же вопросе формулирования сроков ;)
А ещё плюс - разнообразие задач защищали от выгорания.fenrrr Автор
05.09.2023 18:53Привет!
Расскажи пожалуйста, а было ли в таком сетапе у вас проблемы отсутствия подробной документации?
Либо разработчики/тестировщик составлением проектной документации занимались?
Были ли задачи, когда нужно было доработать сервис, который последний раз версионировали год назад? Как разбирались с этим?
А если кто-то из команды ушел из команды - как бы опыт перенимали?
Вопросы без претензий и подколов если что, мне просто интересен опыт твой.ValeryGL
05.09.2023 18:53было ли в таком сетапе у вас проблемы отсутствия подробной документации?
Документированием разработанных фичей в данном случае занимался я (как аналитик) скорее по личностным причинам: разработчики были слишком гордые, чтобы записывать за собой, а мне в таком объеме писать было даже в радость.
Требования и архитектура/проектирование точно были за мной как за аналитиком. Не могу ответить на вопрос с точки зрения «в таком сетапе» :(Либо разработчики/тестировщик составлением проектной документации занимались?
Под проектной документацией я понимаю документы управления проектом - планы календарные, управления коммуникациями, риски и пр., что в PMI PMBoK. По поскольку всея команда на ладони, то из «проектной» документации был только беклог/роадмап.
Были ли задачи, когда нужно было доработать сервис, который последний раз версионировали год назад? Как разбирались с этим?
— ну, аналитик, давай объясняй нам, что это и как работало
— да это вы же сами писали год назад, вы ведь задокументировали за собой, верно?
— вот ты токсик!
— ладно, вот описание на уровне функциональности и архитектура, а глубже сами копайте. «Код - лучшая документация», вы же говорили, - «Там все структурировано и понятно»Есть ощущение, что @fenrrr хотел получить систематизированный ответ, а я скатился до частного случая
fenrrr Автор
05.09.2023 18:53Капитан, полностью взаимно благодарен за комментарий!
Попали просто в яблочко про то, что я хотел донести :)
И второе попадание туда же: в Сбере у меня действительно "команда" состояла из меня, разработчика и двух экспертов со стороны - архитектора и ux-дизайнера. Соответственно и стейкхолдеры были лояльные (и пассивные): видели мое видение, верили мне и не были против моей активности.
В Альфе же я был "играющим тренером" - тимлид-аналитиком. Команда была уже побольше, но менеджерские задачи что по проекту, что по команде, что по процессам никуда не делись))
P.S. Я веду ТГ-канал, где пишу статьи и путевые заметки для аналитиков и тимлидов - буду рад, если примешь приглашение присоединиться! Всегда рад "насмотренным" и бодрым людям в сообществе)
https://t.me/godnolytika
avf48
05.09.2023 18:53Профессиональный стандарт «Руководитель проектов в области информационных технологий».
Профессиональный стандарт «Бизнес-аналитик».
Реестр профессиональных стандартов:
ГОСТ Р 57323-2016/ISO/TS 15926-11:2015 Системы промышленной автоматизации и интеграция. Интеграция данных жизненного цикла перерабатывающих предприятий, включая нефтяные и газовые производственные предприятия. Часть 11. Методология упрощенного промышленного использования справочных данных
Batalmv
Давай начнем с ответственности
ПМ отвечает за выполнение проекта в целом. С него главный спрос. За все :)
Аналитик - за функциональные требования. Т.е. скоуп в части функциональных требований, и их трансляцию во все стороны: продакт, разрабы, тестеры.
Почему-то все сразу начинаю писать про обязанности и т.д., игнорируя базу
Совмещать на небольших проектах - отличная и частая практика.
Вы судя по всему, уже выросли до этого уровня
fenrrr Автор
Добрый день!
Да, но я же начал статью не только с обязанностей, но и как раз с ответственности. Что для меня лично одно и то же почти
Про совмещение на небольших проектах - все так, про это тоже пишу
Спасибо за мнение!
Batalmv
У вас добавлены обязаности продукта. Это характерно для очень маленьких проектов.
Это не обязаности аналитика. Продукт - человек спонсора, которые отвечает за успех продукта, в том числе, и после внедрения.
Просто не имеет смысла ставить вопрос о совмещении роли аналитика и проджекта, когда в реальности у вас все.
У меня было такое на разработке внутреннего демо продукта на 3 спринта. Тогда аналитик действительно совмещает все это, а я помогаю решать технические вопросы + закрываю технические outcomes демо продукта. Но для коммерческого продута - сорчн за прямоту, это либо маленький проект, либо такой стиль организации.
Я когда то работал в большом банке, у них в бизнес вертикали были свои shadow-проекты и shadow ИТ. Они чего то там пилили, иногда даже что-то большое, когда был "придворный" поставщик. Даже часто приходилось с ним интегрироваться в официальных проектах. Хотя момент передачи в поддержку таких "франкенштейнов" вызывал вопросы. Самое забавное, когда такому бизнес "решале" выдавался акт, который надо подписать (а значит и все сделать), чтобы передать систему на поддержку. И тут наступала лютая боль и паника, как у кота, которого застукали на семейном столе за поеданием хозяйской еды. Доки нет, решение и близко не натянуто в отказоустойчивый конфиг, стек под капотом никому не интересен для поддержки, так как спецов нет ...
Поэтому shadow оставалось часто в таком полулегальном положении :) И нам удобно - есть быстрые бойцы, которых можно поймать и применить бесплатно, бизнес двигается и вроде как ИТ-бюджет, кроме затрат на железо, не напрягается
fenrrr Автор
Вот про shadow-проекты - снова с тобой согласен! Ибо в Сбере я такой продукт класса Office Productivity и легализовывал целый год (!). И это та еще история, которую публично рассказывать больно и стыдно.
А про совмещение ролей - перечитайте пожалуйста еще раз цель статьи. Да, свое мнение (основанное на моем опыте и моих проектах) в статье дал. На истину оно не претендует и я его (мнение) не продаю. Оно просто имеет право на сущестование.
Главная цель статьи: дать возможность подумать и подискутировать на тему совмещения ролей. И поделиться своим опытом и мнением. Что вы и другие комментаторы сделали и делают.
За это каждому спасибо!
Batalmv
Shadow проекты и решения - классический отложенный долг. Ура, quick win, вышли на рынок - все верно. Бизнес не нашел ресурсов сделать официально и на коленке собрал сам. Это может жить годами и реально приносить пользу. Но только как нишевое решение.
Но со временем есть риски того, что главный движитель уволится, и центр компетенции развалится, а любая ИТ контора, в том числе и внутренняя попросит 3 цены за взятие его на поддержку. Либо расходы на поддержание станут большими, а работы больше нет, так как ИТ подразделение, наняв админа, дает ему в поддержку 20 систем, а в shadow ИТ у shadow ITшника их две. И получается стоимость уже не радует. Где-то скажется дефицит качественного тестирования
Про компетенции ... почему возникает боль и ржака (внешних наблюдателей) при попытке сдать систему в поддержку официально? Все просто. В акте 10 подписей, под каждым правильная дока, нормально выстроенное решение и много работы. ИТ безопасность вам расскажет про сертификаты, шифрование, аутентификацию, ЭЦП, корректную работу с персональными данными ... а у shadiw- проекте этого либо нет, либо сделано так, что без слез не взглянешь. А почему? Потому что это надо было вписывать в задачи отдельно, а значит тратить свое время, которого не было из-за совмещения, да и часто нехватки знаний (так как опытный спец сразу знает, как правильно и потратит децл времени, а shadow швейцарский ножик уйдет со встречи гуглить половину терминов). Архитектура спросит, а чего вы будете делать при отказе этого квадратика. А окажется, что данные пропадут, а аргумент, что до того ничего не падало не проканает. А на отказоустойчивость надо потратить много времени, и своего, и команды. Злая разработка попросит покрытие unit-тестами 75% кода и результаты сканера, после чего пошлет shadow команду с папиоусом километровой длины
Shadow подход - это почти всегда компромис где все, кроме функциональных требований выпадает в осадок. Поэтому ЕСТЬ ВРЕМЯ совмещать. Но если делать продукт под корпоративные стандарты качества - швейцарский ножик, как правило, сразу или чуть погодя поймет, что уже так не работает
fenrrr Автор
Огромное спасибо за историю! Меня прям передернуло от флешбеков)
Оформил ваши комментарии как пост в своем канале, в теле поста сослался на ваш профиль - https://t.me/godnolytika/143