Комментарии 9
В последнее время все чаще встречаются компании-консультанты, предлагающие архитектуру как сервис. Выходной документ - arc42 с диаграммами по C4 Model и расчетом ежемесячных расходов в том или ином облаке. Такая стандартизация очень заманчиво смотрится, потому что позволяет выпускать RFP для любого исполнителя. Но гладко оно лишь на бумаге, как известно. Спасибо за статью.
О, хороший длиннопост и без комментариев - классика Хабра!
Буду исправлять, потому как ненавижу тишину и под своими постами. Не уверен, что осилю за раз, так что буду отписывать по ходу чтения. Опыт похожий, но со стороны архитектора и большего числа проектов, видно и другие детали.
на старте проекта закладывались вопросы и риски, которые невозможно было решить без серьезного пересмотра требований к решению и как результат последующего перезапуска проекта.
Это логично, потому что Закон Парето никто не отменял. Основной загвоздкой является клиент. Пару раз довелось работать с консультантами из больших с самого начала. Много раз видел выкладки с рекомендацией консультанта и абсолютно другое требование в RFP.
консультант уже не несет прямой ответственности за качество требований перед клиентом
В половине проектов, я видел консультантов и в стадии разработки на должности типа Program Architect и даже на стадии первичных UAT. Big4 стараются гарантировать обоснованность своей работы (они очень дорого берут за свое имя и потому сильно дорожат им) и доказать свою незаменимость (как раз основываясь на решениях клиента "вопреки" и на факте изменения требований с течением времени). Им очень выгодно нести эту ответственность, так как на самом деле они играют в стрелки, обосновывая проблемы либо решениями заказчика, либо ошибками разработчика (а там часто ещё и обслуживанием занимается кто-то третий). Проект то явно на год (-ы) разработки и любой аудитор захочет сидеть и назначать виноватых за большие деньги в течении всего этого срока.
На самом раннем этапе внедрять процедуру управления изменениями, показывать клиенту риски, включая технологические риски
Отлично, только у нас не ватерфол, так что проработанных требований всё равно не будет, а если вы уже согласились (подписали), то уповать вам стоит только на адекватность заказчика. Обычно все понимают правила игры, но в случае форс мажора (допустим смена руководителей или промах по бюджету и срокам), вполне могут вспомнить формальности.
Обычно все стороны хороши. И сейлзы со стороны разработчика (ваши) вписывают вас в проект не глядя, чтоб получить свои лёгкие деньги. Никогда не видел, чтоб бонус они получали по факту сдачи проекта клиенту. Только серьёзные убытки заставили одну компанию включить архитектора в пресейл, чтоб он мог делать ту самую валидацию требований, до подписания и взятых обязательств.
Спасибо за комментарии по первому разделу)
В половине проектов, я видел консультантов и в стадии разработки на должности типа Program Architect и даже на стадии первичных UAT. Big4 стараются гарантировать обоснованность своей работы (они очень дорого берут за свое имя и потому сильно дорожат им) и доказать свою незаменимость (как раз основываясь на решениях клиента "вопреки" и на факте изменения требований с течением времени). Им очень выгодно нести эту ответственность, так как на самом деле они играют в стрелки, обосновывая проблемы либо решениями заказчика, либо ошибками разработчика (а там часто ещё и обслуживанием занимается кто-то третий). Проект то явно на год (-ы) разработки и любой аудитор захочет сидеть и назначать виноватых за большие деньги в течении всего этого срока.
тут похоже мы сходимся во мнениях. Подход, когда консультантом при формировании требований и аудитором на стадии реализации является одно и то же юр-лицо, по-моему влечет конфликт интересов. Эту мысль пытался донести.
Отлично, только у нас не ватерфол, так что проработанных требований всё равно не будет, а если вы уже согласились (подписали), то уповать вам стоит только на адекватность заказчика. Обычно все понимают правила игры, но в случае форс мажора (допустим смена руководителей или промах по бюджету и срокам), вполне могут вспомнить формальности.
не waterfall на каком уровне? На уровне программы проектов как раз waterfall. Сначала проект Консультанта, потом конкурс, потом реализация. И даже на уровне проекта по разработке случается видеть waterfall, когда привязывают платежи к этапам, как в проектах внедрения готовых приложений. Вопрос же не в том, что требования не могут меняться и уточняться. А в том, что требования на входе были некачественные и неполные и при этом достаточно сложно требования поменять, уточнить по причинам, описанным в статье.
Обычно все стороны хороши. И сейлзы со стороны разработчика (ваши) вписывают вас в проект не глядя, чтоб получить свои лёгкие деньги. Никогда не видел, чтоб бонус они получали по факту сдачи проекта клиенту. Только серьёзные убытки заставили одну компанию включить архитектора в пресейл, чтоб он мог делать ту самую валидацию требований, до подписания и взятых обязательств
здесь двух мнений быть не может) Конечно, на этапе продажи можно было бы подложить соломки. На самом деле архитекторы были всегда на пресейле. Даже выполнялись тестовые задания. Вопрос: почему договор оказывается невыполнимым с т.з. требований и управления изменениями - очевидно можно адресовать к команде продаж.
Agile на глобальном уровне, то waterfall всегда локальный. Сприт будет проектироваться детально, phase планируем большими кускам, а проект на уровене ключевых моментов и общих понятий. Это в архитектуре так. Решили микросервисы, потом разбили на сервисы, общая инфраструктура, потом продумали каждый отдельный сервис. Поэтому ожидать от консультанта деталей неправильно. Это не реально продумать всё, для команды пришедшей снаружи на 3 - 6 месяцев. А больше клиент платить не будет. И, обычно, клиент хочет, чтоб консультант задокументировал его (клиента) видение решения (облако хотим в амазике!), а проф. консультанты, всё же, хотят докопаться до требований (почему облако и почему именно у этого провайдера). Это долго и конфликтно. В конце концов, мы приходим к тому самому "время-деньги" и консультант "отпускает" часть требований в свободное плавание по RFP - кто купиться на это, тот и будет расхлёбывать...
Сама система (разделение консультант-клиент-разработчик) вполне оправдана, так как это меньшее из зол. У всех есть свои интересы и тройственность союза заставляет договариваться.
Пост дочитал, интересно, но не ожидайте дискуссии. Резонанс вызывают статьи, где можно поспорить. Людей с вашим опытом тут мало, а те у кого он есть, скорее согласятся, чем будут оспаривать ваши выводы.
Статья понравилась, много здравых рассуждений, но включиться в дискуссию сложновато, поскольку материал обо всем и сразу.
Если хватит сил и желания, то мне, к примеру, было бы интересно узнать детали выстраивания процесса не на уровне идеи, а в нюансах воплощения. Как подружить слова Git, Pull-Request, SonarQube, Quality Gate и обеспечить контроль за исходниками - это понятно, это история распространенная. А вот как подружить слова аналитик, Acceptance Test в постановке, Gherkin, Acceptance Test Review и Quality Gate - это уже нераспространенная история, если у вас существует решение не на уровне должностной инструкции, а такое, которое физически не пустит в работу задачу без определения сценария приемочного теста, если этот тест не прошел ревью, если всё, что связано с постановкой не преодолело связанный с этим Quality Gate, в котором установлены некие конкретные критерии, то про это решение было бы очень интересно узнать. У нас, как-то так получается, что любые заходы к аналитикам заканчиваются на уровне "а, так это че-т делать надо, в чем-то разбираться? не, идея классная, но у нас сейчас другое совещание начнется, давайте завтра. Или лучше знаете что, лучше никогда!"
не на уровне должностной инструкции, а такое, которое физически не пустит в работу задачу без определения сценария приемочного теста, если этот тест не прошел ревью, если всё, что связано с постановкой не преодолело связанный с этим Quality Gate, в котором установлены некие конкретные критерии, то про это решение было бы очень интересно узнать. У нас, как-то так получается, что любые заходы к аналитикам заканчиваются на уровне "а, так это че-т делать надо, в чем-то разбираться? не, идея классная, но у нас сейчас другое совещание начнется, давайте завтра. Или лучше знаете что, лучше никогда!"
это очень хороший вопрос) Потому что на одном из проектов выделили целую команду, которая описывала процессы в конфлюенс. Процессы были классными, читались на одном дыхании. Одна только проблема: никто эти процессы не внедрял)
Ответ же есть: "BDD являются предпосылки, при которых этот подход работает. Иначе получится лишь имитация подхода". Вы пишете, что аналитики не хотят. Совещания и т.п. Ответ очевиден - если очень хочется внедрить BDD придется поменять аналитиков. Либо обучить, либо физически поменять. Более того, ни на одном из проектов в объемах всего проекта не удалось внедрить BDD. Получилось сделать только в паре команд разработки. Но возможно, я что-то делал не так)
Спасибо за полную статью! Рассказали и объяснили все необходимые детали. Дочитал все таки до конца, но проектами не занимаюсь - все равно интересно))
Здесь качественного материала на двадцать статей, а не на одну. Редкая птица долетит до середины. Может быть автор подумает о серии статей, в каждой по отдельной теме?
Автору -- спасибо! Много кейсов, из упомянутых в статье, самому встречались в производственной деятельности, но и много нового. Отличная статья!
Записки технического руководителя проектов