Некое общее замечание, в контексте статьи лучше бы разделить системы на следующие отдельные части:
1. Источники данных — как правило это учетные системы (1C, Axapta, OEBS, SAP etc), которые уже существуют.
2. ETL средства, с помощью которых данные из источников перегружаются в…
3. Хранилище (в узком смысле слова). Которым может быть как обычная реляционная БД, так и настоящая многомерка типа essbase (прошу прощения у поклонников olap options etc) и которое предоставляет данные…
4. ПО «генерации отчетов» (звучит не красиво, не нашел другого перевода reporting software), для получения отчетов конечными пользователями.
Смешивать п.3 и 4 ошибочно, например вы можете иметь хранилище на SAP BW, но получать из него отчеты средствами Oracle BI EE. Или получать данные из Oracle Hyperion Essbase с помощью Microsoft Excel.
Иногда п. 2-3 можно пропустить и забирать данные например с помощью Excel или BOBJ сразу из учетной системы. Но у такого подхода есть несколько минусов:
— При большом объеме данных в учетной системе и\или большом числе отчетов, отчеты могут «убить» учетную систему создав слишком большую нагрузку.
— Если данные лежат в нескольких источниках (1С, CRM, HR), то объединение данных «на лету» без хранилища или технологически\организационно сложно, или опять же может быть ресурсоемко (читай дорого по железу, или медленно по времени генерации отчетов). Но, повторюсь, чисто теоретически строить отчеты прямо на учетной системе можно.
Исходя из этого замечания, а также потребностей (количество пользователей, их подготовки, потребности в отчетах) а также возможностей компании (финансовых) выбирают пункты 2-4.
Избавление ИТ от ad-hoc или рождение OLAP. Начало проекта BI.
Противопоставлять ad-hoc и OLAP по меньшей мере странно, это понятия из разных областей: ad-hoc это, упрощенно, отчет который является ответом на вопрос, который (вопрос) родился здесь и сейчас.
Поэтому ad-hoc, это прямая противоположность регламентным отчетам, которые имеют заранее установленную форму и не меняются.
Собственно ad-hoc отчеты можно делать прямо на OLAP источниках (если под OLAP автор понимает многомерные источники-«кубы»).
По поводу ценников: цена складывается не только из цен на лицензии, но и включает, например, и стоимость дальнейшей поддержки решения. Да, лицензии на Oracle BI действительно дороги в редакции EE, но для малых предприятий есть Standard Edition One с более умеренным ценником. А вот если сравнить количество резюме специалистов на hh.ru по QlikView и Oracle BI, то выяснится, что спецов по последнему в разы больше, чем по QlikView.
В заключении хотелось бы сказать, что если у заказчика нет собственной сильной команды, то лучше таки потратить время на встречи с интеграторами, чем внедрить «не то и не так». Если говорить о крупных (ТОП-5) интеграторах, то от запроса до контракта может пройти месяц, но очень редко год (не повезло). Длительность внедрения зависит от масштабов проекта и уже мало зависит от размера внедренца.
Отвечая на заголовок:
Когда пора задуматься о внедерении BI-системы?
тогда, когда владельцы хотят иметь отчетность быстро, с прозрачными и проверяемыми цифрами и готовы за это платить. Все остальное — выбор софта, внедренцев и прочее, это уже детали, главное понять, что иногда ручками в excel долго, неточно, и в конечном счете «дорого» за счет не верно принятых на основе таких отчетов, решений.
Я под «широкими санкциями» понимаю отключение либо всех банков РФ, либо банков из ТОП-5 типа Сбера, Альфы, ГПБ и иже с ними. Про Россию и СМП я написал в п3. но доля этих банков, согласитесь, не очень велика…
Только мне кажется объяснение проблем «техническим сбоем» немного подозрительным?
1. В 2013-2014 банки (Пушкино, БПФ, Мастер etc) довольно часто объясняли возникшие проблемы именно техническим сбоем. И только потом выяснялось, что у кого-то плохо с ликвидностью, с резервами или не все в порядке с отмыванием денег.
2. Технический сбой безусловно возможен, люди ошибаются, сервера ломаются… но когда функционал есть, он работает, а потом исчезает и период его восстановления декларируется не 1-2 дня, а дней 10 (как худший вариант 31 марта) то возникает вопрос, что такое могло сломаться, что будут восстанавливать так долго?
3. У нескольких банков (СМП, Собинбанк, Россия) возникли проблемы с картами Visa и MasterCard.
Сейчас слабо верится, что Visa или MC введут широкие санкции, ну так и про цензуру в интернете когда-то тоже так думали. Как итог от Яндекса хотелось бы чуть больше открытости и чуть больше информации, а не просто «проблема техническая».
Confluence уже используется, но преимущественно как база для обмена опытом. Повторюсь, word удобен бизнесу, удобен менеджменту ИТ, т.к. нужны печатные версии для отчетности, word имеет плагин для ClearCase и т.д.
Само же согласование интерактивно, никто не редактирует документы в прямом смысле слова одновременно. Чтобы документ не «потерялся в почте», его выкладывают на портал, откуда забирают на редактирование прямо через интерфейс ms word. Более того, ms word в связке с sharepoint позволяют видеть, кто какие правки вносил и предоставляют возможность удобно мерджить несколько версий документа. Не сочтите за рекламу MS, но это действительно удобно.
Но, уверен, одна из главных причин — бизнес пользователи знают и умеют работать в ворде, заставить их пересесть в Confluence — низовое звено еще пересядет, среднее звено и выше — никогда.
Давайте разберем конкретный кейс, чтобы спуститься с абстрактных рассуждений до конкретного примера:
Заказчик хочет новую форму расчета бонуса с продаж. Функционально задача касается нескольких команд:
1. Есть хранилище, где лежат данные по продажам. Поддерживает DWH одна команда.
2. Информация по платежам и ФОТу лежит, условно, в HRMS, который поддерживает вторая команда.
3. Бонус зависит в т.ч. от KPI подразделения и филиала в целом, которые вычисляется в третьей коробке Balanced ScoreCard Manager.
4. Системы, упомянутые в п.1-3 это backend, интерфейс к ним разрабатывает четвертая команда (на самом деле интерфейс к DWH разрабатывает еще одна команда BI).
Теперь внимание вопрос: кому из ребят достанется заказ? Можно отдавать тем, на чей модуль ляжет больше функционала. Можно отдавать тем, у кого есть свободные ресурс. Можно отдавать тем, кто лучше (в срок и бюджет) выполнил предыдущую задачу. Все эти критерии очень условно, функционал плохо взвешивается, все друг с другом воюют за деньги и власть. Плюс т.к. функциональность касается нескольких систем, кто будет контролировать процесс в целом? Чтобы и рукава и пуговицы были в порядке и никто из команд не тянул одеяло сроков и денег на себя?
Второй момент — если аналитик прикреплен к команде, то он не видит картинки в целом и просто не знает, что делали соседи. Значит нужен аналитик, точнее архитектор, кто видит картинку сверху и знает, хотя бы по верхам, что делает каждая команда.
Нет, люди не передаются. Если люди простаивают временно — се ля ви
Простите, но людям в простое надо платить зарплату? Если да, но при этом ресурсы умышленно не балансируются между командами — вы такой подход нивжисть не объясните бизнесу.
Есть главный ПМ проекта и главный технический лидер
Так а я о чем? Есть главный РП, есть несколько архитекторов, один их них главный, есть команды со своими лидами. В результате получилась текущая схема, с «адовой» иерархией: РП-мастерлид-лид-разработчик. Убрать мастерлидов не получится, если у лида не более 7-ми разработчиков, то получится что РП надо будет общаться с 20-30 лидами, что полностью убьет управляемость.
Т.е. сама идея горизонтального масштабирования жизнеспособна и в какой-то мере красива, но как ее применить у себя — способа не вижу.
Вы описали очень крутой ад. Ничего лучше горизонтально масштабированной структуры с инкапсуляцией всех компетенций внутри команд (анализ+разработка +тестирование) еще не придумали
Если я вас правильно понимаю, речь про множество сравнительно небольших команд, в каждой из которых присутствуют все нужные для разработки компетенции? Если так, то мы это проходили — не срослось. Простые кейсы:
1. Пришел новый запрос, кто решает в какую из команд его отдавать?
2. Ок, как-то решили, какая из мини команд делает, как обеспечить чтобы новый функционал нормально жил с уже существующим (не дублировал, то что уже есть, использовал интерфейсы к внешним системам, которые — интерфейсы, уже описаны и зафиксированы etc)?
3. Будет ли балансировка ресурсов между командами? Условно — у кого-то простаивает 5-ть разработчиков, а в другой команде завал — люди будут «передаваться» из команды в команду?
4. Как планировать финансы на все команды? Сверху вниз или снизу вверх? В первом варианте кто будет решать, кому какая доля, а во втором, кто будет защищать бюджеты перед топами?
5. Кто несет ответственность за весь проект в целом? В том смысле кто репортит топам за весь проект, кого режут на части в случае факапа, кто консолидирует требования от миникоманд, чтобы, например вместо 10-ти минисерверов разработки для каждой команды купить одну мега-железку?
Для ответов на все эти вопросы и существует адова иерархия с единой для всех командой архитекторов, единой командой мастер-лидов для балансировки ресурсов, единым менеджером…
Впрочем, я нахожусь внутри, поэтому изначально субъективен, если есть успешные кейсы, скажите где смотреть, читать или куда напрашиваться на референс визит — буду искренне благодарен, сам устал от всей этой иерархии.
Опишите пожалуйста проблемы из-за которых было принято решение мигрировать с Perl. Не холивара ради, просто чтобы все перловики знали где нужно быть осторожней.
Решение, насколько я знаю, принималось в конце прошлого\начале текущего века — так что могу только гадать на основе «случайно услышанных баек». Инициатором миграции была верхушка ИТ блока, цели — самые благородное: необходима платформа для больших проектов, от известного вендора, с поддержкой, желательно поставляющего вообще весь стек ИТ продуктов. Собственно альтернатив J2EE на тот момент, как я понимаю не было: Microsoft Net только становился на ноги. Позиции IBM в финансовом секторе вообще и в банке в частности были сильны, так что голубой гигант победил без особой борьбы: IBM стал не только поставщиком железа и сервисов, но протолкнул и вебсферу (не портал, только application server). Ключевые слова в продаже, думаю, с тех пор не сильно изменились: поддержка крупного вендора, масштабируемость, надежность.
по поводу 8-ми часов: реальной разработкой программист занимается не более 3-4 часов в день, остальное время он думает, общается с коллегами и просто чистит мозг (анекдоты, танки, etc). здесь слова «думает, общается и чистит» — не несут негативного оттенка, это данность, которую надо принять. разрабатывать по 6-8 часов в день на протяжении длительного периода невозможно — просто снесет крышу.
Учусь на мастера. Первое чему нас стал учить немецкий профессор на веб-инжиниринге, что все члены команды должны работать не более 8 часов и строго с выходными/праздниками, иначе люди быстро теряют мотивацию, продуктивность и все такое. В жизни похоже все не так идеально, или все таки дело в проблемах организации?
два момента: первый — здесь речь шла именно про украинскую команду на нашем конкретном проекте. например венгры на проекте, на мой взгляд немного ленивы — они уже восприняли немецкий порядок в части соблюдения рабочего режима, но еще не восприняли немецкую дисциплину и чай пью когда им хочется, а не в специально отведенный получасовой перерыв один раз в день.
второй момент — именно для украинской команды такие переработки их собственная инициатива. во-первых парни видят перспективу (их мотивация): их лид вырос из junior и сейчас зарабатывает чуть ли не в полтора раза больше, чем средняя ЗП лида его квалификации в Киеве. во-вторых на проекте многому можно научиться, есть очень сильные спецы, готовые помочь, есть сложные не рутинные задачи. и третье, что как я понял привлекает — есть ощущение стабильности работодателя. банк конечно это не вам не газпром, но кризисы и 1998 и 2008 прошел, команда проекта в те времена только усилилась за счет сильных спецов, ушедших из других банков.
как итог — никто не заставляет работать по 10 часов, но если людям интересно, запрещать не будут
А не пробовали такой же фокус провести со своей коммандой Java разработки?
Что-то подобное пробовали, с украинскими разработчиками получилось так:
Молодежь и так работает по 10-11 часов, из которых, правда, часов восемь курит доки и изобретает велосипед набирается опыта. К ним претензий нет — взяты на вырост.
Многоопытных старцев тоже не тронешь — когда случится факап, они могут найти и исправит ошибку в коробочном ПО вендора, который давно прекратил свое существование или втроем заменить команду из пяти венгров, так некстати отравившихся на праздновании дня независимости, и все сделают в срок.
Остаются разработчики среднего, как по возрасту так и квалификации, уровня. Опыта уже набравшие, но еще не заматеревшие — только вот они тоже цену себе знают и ведутся на такой спектакль только раз.
Тут нужен индивидуальный подход чуть ли не к каждому, причем «внушение» должен делать человек имеющий в глазах людей репутацию отличного разработчика. Формальная власть или власть харизмы здесь не срабатывала, только экспертная.
Хотелось бы упрощения процесса и снижения уровня формализма (ох уж этот Ordnung), но умом понимаю, что проект с командой такого размера, просто неминуемо обрастает формальными процедурами. То что мы видели в паре банков конкурентов (в Европе и Китае), очень похоже на существующее у нас. С российским опытом практически не знаком — слышал позитивные отзывы о ВТБ и разные отзывы о Сбербанке, но с ними не работал и подробностей организации процесса просто не знаю. Уверен, что улучшить схему, хотя бы в части повышения оперативности, можно (так что советы крайне приветствуются).
По второму вопросу: схема сознательно упрощена, под шагом
5. Разработчик забирает последнюю версию исходных кодов, производит реализацию функционала.
скрывается примерно такой же объемный процесс определения функционального домена, выделения конкретного разработчика, контроля реализации, передачи функционала в поддержку, документированию etc. Аналогично шаги 1-2 раскрываются в схему бюджетирования, согласования функционала и прочее. В работах на этих этапах менеджер проекта принимает некоторое участие, но, по большому счету, работа менеджера сводится к замечательно формулировке «ты несешь ответственность за весь этот бардак», что означает репорты руководству, решение форс-мажоров и выбивание бюджета на следующий квартал\год. Большую часть работы руками выполняют ассистенты, мастер-тимлиды и архитектора.
1. Источники данных — как правило это учетные системы (1C, Axapta, OEBS, SAP etc), которые уже существуют.
2. ETL средства, с помощью которых данные из источников перегружаются в…
3. Хранилище (в узком смысле слова). Которым может быть как обычная реляционная БД, так и настоящая многомерка типа essbase (прошу прощения у поклонников olap options etc) и которое предоставляет данные…
4. ПО «генерации отчетов» (звучит не красиво, не нашел другого перевода reporting software), для получения отчетов конечными пользователями.
Смешивать п.3 и 4 ошибочно, например вы можете иметь хранилище на SAP BW, но получать из него отчеты средствами Oracle BI EE. Или получать данные из Oracle Hyperion Essbase с помощью Microsoft Excel.
Иногда п. 2-3 можно пропустить и забирать данные например с помощью Excel или BOBJ сразу из учетной системы. Но у такого подхода есть несколько минусов:
— При большом объеме данных в учетной системе и\или большом числе отчетов, отчеты могут «убить» учетную систему создав слишком большую нагрузку.
— Если данные лежат в нескольких источниках (1С, CRM, HR), то объединение данных «на лету» без хранилища или технологически\организационно сложно, или опять же может быть ресурсоемко (читай дорого по железу, или медленно по времени генерации отчетов). Но, повторюсь, чисто теоретически строить отчеты прямо на учетной системе можно.
Исходя из этого замечания, а также потребностей (количество пользователей, их подготовки, потребности в отчетах) а также возможностей компании (финансовых) выбирают пункты 2-4.
Противопоставлять ad-hoc и OLAP по меньшей мере странно, это понятия из разных областей: ad-hoc это, упрощенно, отчет который является ответом на вопрос, который (вопрос) родился здесь и сейчас.
Поэтому ad-hoc, это прямая противоположность регламентным отчетам, которые имеют заранее установленную форму и не меняются.
Собственно ad-hoc отчеты можно делать прямо на OLAP источниках (если под OLAP автор понимает многомерные источники-«кубы»).
По поводу ценников: цена складывается не только из цен на лицензии, но и включает, например, и стоимость дальнейшей поддержки решения. Да, лицензии на Oracle BI действительно дороги в редакции EE, но для малых предприятий есть Standard Edition One с более умеренным ценником. А вот если сравнить количество резюме специалистов на hh.ru по QlikView и Oracle BI, то выяснится, что спецов по последнему в разы больше, чем по QlikView.
В заключении хотелось бы сказать, что если у заказчика нет собственной сильной команды, то лучше таки потратить время на встречи с интеграторами, чем внедрить «не то и не так». Если говорить о крупных (ТОП-5) интеграторах, то от запроса до контракта может пройти месяц, но очень редко год (не повезло). Длительность внедрения зависит от масштабов проекта и уже мало зависит от размера внедренца.
Отвечая на заголовок:
тогда, когда владельцы хотят иметь отчетность быстро, с прозрачными и проверяемыми цифрами и готовы за это платить. Все остальное — выбор софта, внедренцев и прочее, это уже детали, главное понять, что иногда ручками в excel долго, неточно, и в конечном счете «дорого» за счет не верно принятых на основе таких отчетов, решений.
1. В 2013-2014 банки (Пушкино, БПФ, Мастер etc) довольно часто объясняли возникшие проблемы именно техническим сбоем. И только потом выяснялось, что у кого-то плохо с ликвидностью, с резервами или не все в порядке с отмыванием денег.
2. Технический сбой безусловно возможен, люди ошибаются, сервера ломаются… но когда функционал есть, он работает, а потом исчезает и период его восстановления декларируется не 1-2 дня, а дней 10 (как худший вариант 31 марта) то возникает вопрос, что такое могло сломаться, что будут восстанавливать так долго?
3. У нескольких банков (СМП, Собинбанк, Россия) возникли проблемы с картами Visa и MasterCard.
Сейчас слабо верится, что Visa или MC введут широкие санкции, ну так и про цензуру в интернете когда-то тоже так думали. Как итог от Яндекса хотелось бы чуть больше открытости и чуть больше информации, а не просто «проблема техническая».
Само же согласование интерактивно, никто не редактирует документы в прямом смысле слова одновременно. Чтобы документ не «потерялся в почте», его выкладывают на портал, откуда забирают на редактирование прямо через интерфейс ms word. Более того, ms word в связке с sharepoint позволяют видеть, кто какие правки вносил и предоставляют возможность удобно мерджить несколько версий документа. Не сочтите за рекламу MS, но это действительно удобно.
Но, уверен, одна из главных причин — бизнес пользователи знают и умеют работать в ворде, заставить их пересесть в Confluence — низовое звено еще пересядет, среднее звено и выше — никогда.
Заказчик хочет новую форму расчета бонуса с продаж. Функционально задача касается нескольких команд:
1. Есть хранилище, где лежат данные по продажам. Поддерживает DWH одна команда.
2. Информация по платежам и ФОТу лежит, условно, в HRMS, который поддерживает вторая команда.
3. Бонус зависит в т.ч. от KPI подразделения и филиала в целом, которые вычисляется в третьей коробке Balanced ScoreCard Manager.
4. Системы, упомянутые в п.1-3 это backend, интерфейс к ним разрабатывает четвертая команда (на самом деле интерфейс к DWH разрабатывает еще одна команда BI).
Теперь внимание вопрос: кому из ребят достанется заказ? Можно отдавать тем, на чей модуль ляжет больше функционала. Можно отдавать тем, у кого есть свободные ресурс. Можно отдавать тем, кто лучше (в срок и бюджет) выполнил предыдущую задачу. Все эти критерии очень условно, функционал плохо взвешивается, все друг с другом воюют за деньги и власть. Плюс т.к. функциональность касается нескольких систем, кто будет контролировать процесс в целом? Чтобы и рукава и пуговицы были в порядке и никто из команд не тянул одеяло сроков и денег на себя?
Второй момент — если аналитик прикреплен к команде, то он не видит картинки в целом и просто не знает, что делали соседи. Значит нужен аналитик, точнее архитектор, кто видит картинку сверху и знает, хотя бы по верхам, что делает каждая команда.
Простите, но людям в простое надо платить зарплату? Если да, но при этом ресурсы умышленно не балансируются между командами — вы такой подход нивжисть не объясните бизнесу.
Так а я о чем? Есть главный РП, есть несколько архитекторов, один их них главный, есть команды со своими лидами. В результате получилась текущая схема, с «адовой» иерархией: РП-мастерлид-лид-разработчик. Убрать мастерлидов не получится, если у лида не более 7-ми разработчиков, то получится что РП надо будет общаться с 20-30 лидами, что полностью убьет управляемость.
Т.е. сама идея горизонтального масштабирования жизнеспособна и в какой-то мере красива, но как ее применить у себя — способа не вижу.
Если я вас правильно понимаю, речь про множество сравнительно небольших команд, в каждой из которых присутствуют все нужные для разработки компетенции? Если так, то мы это проходили — не срослось. Простые кейсы:
1. Пришел новый запрос, кто решает в какую из команд его отдавать?
2. Ок, как-то решили, какая из мини команд делает, как обеспечить чтобы новый функционал нормально жил с уже существующим (не дублировал, то что уже есть, использовал интерфейсы к внешним системам, которые — интерфейсы, уже описаны и зафиксированы etc)?
3. Будет ли балансировка ресурсов между командами? Условно — у кого-то простаивает 5-ть разработчиков, а в другой команде завал — люди будут «передаваться» из команды в команду?
4. Как планировать финансы на все команды? Сверху вниз или снизу вверх? В первом варианте кто будет решать, кому какая доля, а во втором, кто будет защищать бюджеты перед топами?
5. Кто несет ответственность за весь проект в целом? В том смысле кто репортит топам за весь проект, кого режут на части в случае факапа, кто консолидирует требования от миникоманд, чтобы, например вместо 10-ти минисерверов разработки для каждой команды купить одну мега-железку?
Для ответов на все эти вопросы и существует адова иерархия с единой для всех командой архитекторов, единой командой мастер-лидов для балансировки ресурсов, единым менеджером…
Впрочем, я нахожусь внутри, поэтому изначально субъективен, если есть успешные кейсы, скажите где смотреть, читать или куда напрашиваться на референс визит — буду искренне благодарен, сам устал от всей этой иерархии.
Решение, насколько я знаю, принималось в конце прошлого\начале текущего века — так что могу только гадать на основе «случайно услышанных баек». Инициатором миграции была верхушка ИТ блока, цели — самые благородное: необходима платформа для больших проектов, от известного вендора, с поддержкой, желательно поставляющего вообще весь стек ИТ продуктов. Собственно альтернатив J2EE на тот момент, как я понимаю не было: Microsoft Net только становился на ноги. Позиции IBM в финансовом секторе вообще и в банке в частности были сильны, так что голубой гигант победил без особой борьбы: IBM стал не только поставщиком железа и сервисов, но протолкнул и вебсферу (не портал, только application server). Ключевые слова в продаже, думаю, с тех пор не сильно изменились: поддержка крупного вендора, масштабируемость, надежность.
два момента: первый — здесь речь шла именно про украинскую команду на нашем конкретном проекте. например венгры на проекте, на мой взгляд немного ленивы — они уже восприняли немецкий порядок в части соблюдения рабочего режима, но еще не восприняли немецкую дисциплину и чай пью когда им хочется, а не в специально отведенный получасовой перерыв один раз в день.
второй момент — именно для украинской команды такие переработки их собственная инициатива. во-первых парни видят перспективу (их мотивация): их лид вырос из junior и сейчас зарабатывает чуть ли не в полтора раза больше, чем средняя ЗП лида его квалификации в Киеве. во-вторых на проекте многому можно научиться, есть очень сильные спецы, готовые помочь, есть сложные не рутинные задачи. и третье, что как я понял привлекает — есть ощущение стабильности работодателя. банк конечно это не вам не газпром, но кризисы и 1998 и 2008 прошел, команда проекта в те времена только усилилась за счет сильных спецов, ушедших из других банков.
как итог — никто не заставляет работать по 10 часов, но если людям интересно, запрещать не будут
В Jira задача заводится, часто лишь с кратким описанием, файл с полной постановкой просто прикрепляется.
Что-то подобное пробовали, с украинскими разработчиками получилось так:
Молодежь и так работает по 10-11 часов, из которых, правда, часов восемь курит доки и
изобретает велосипеднабирается опыта. К ним претензий нет — взяты на вырост.Многоопытных старцев тоже не тронешь — когда случится факап, они могут найти и исправит ошибку в коробочном ПО вендора, который давно прекратил свое существование или втроем заменить команду из пяти венгров, так некстати отравившихся на праздновании дня независимости, и все сделают в срок.
Остаются разработчики среднего, как по возрасту так и квалификации, уровня. Опыта уже набравшие, но еще не заматеревшие — только вот они тоже цену себе знают и ведутся на такой спектакль только раз.
Тут нужен индивидуальный подход чуть ли не к каждому, причем «внушение» должен делать человек имеющий в глазах людей репутацию отличного разработчика. Формальная власть или власть харизмы здесь не срабатывала, только экспертная.
По второму вопросу: схема сознательно упрощена, под шагом
скрывается примерно такой же объемный процесс определения функционального домена, выделения конкретного разработчика, контроля реализации, передачи функционала в поддержку, документированию etc. Аналогично шаги 1-2 раскрываются в схему бюджетирования, согласования функционала и прочее. В работах на этих этапах менеджер проекта принимает некоторое участие, но, по большому счету, работа менеджера сводится к замечательно формулировке «ты несешь ответственность за весь этот бардак», что означает репорты руководству, решение форс-мажоров и выбивание бюджета на следующий квартал\год. Большую часть работы руками выполняют ассистенты, мастер-тимлиды и архитектора.