Серия псевдофилософских мини-эссе о работе функционального архитектора.
Про записи архитектурных решений
Очень полезная практика – осознанно записывать архитектурные решения, принятые на проекте. Желательно сопровождать это описанием причин, по которым был сделан выбор в пользу принятого решения. В идеале дополнять описанием альтернативных вариантов решения, которые рассматривались, с их ключевыми плюсами и минусами.
Делать это нужно в каждой ситуации дуальности. Даже если в моменте принятое решение кажется вам очевидным.
Будем честны, в коротких проектах, ничего кроме прокачки самодисциплины это не даст. Но в среднесрочных и длительных проектах, спустя время, вы сами себе скажете спасибо.
Место записи может быть разным – отдельный проектный артефакт или выделенный раздел в артефактах проектирования доработок. В качестве бонуса можно прикрутить к этой истории ИИ, чтобы он анализировал записи архитектурных решений текущего и предыдущих проектов и помогал быстро искать ответ на главный вопрос, с которым работают архитекторы – «почему мы так делаем?».
Про смысловой инкремент
Когда мы говорим о проектах внедрения финансовых бизнес-приложений, то практика показывает, что почти всегда в матрице Стейси мы находимся в зоне «водопада», а не в зоне «аджайла». Т.к. в целом мы понимаем требования (ось уровня согласия) и как их реализовывать (ось уверенности).
Рассмотрим классическую этапность проектов при «водопаде». Анализ → Проектирование → Разработка → ПСИ → Подготовка к эксплуатации → Эксплуатация. Каждый этап сопровождается определенным набором проектных артефактов. Структура и принципы наполнения артефактов регламентируются используемой проектной технологией. А вот уровень детализации артефактов – вопрос дебатируемый.
Оптимальным видится следующий подход. Т.к. выше мы определились, что у нас высокий уровень определенности, то можно говорить, что мы изначально видим целевую систему целиком, но только в минимальной степени проработки. Следовательно, можно сформулировать следующее правило – каждый проектный артефакт должен нести смысловой инкремент. Таким образом мы постепенно повышаем степень проработки системы от 0 % до 100 %. Возвращаясь к исходному вопросу, получаем, что уровень детализации проектных артефактов должен быть в диапазоне от «проектный артефакт вообще не несет смысловой инкремент» до «проектный артефакт проработан настолько, что в артефакте следующего этапа вообще не остается места для смыслового инкремента». Соответственно, если проектный артефакт не несет смысловой инкремент, то его можно вообще не делать.
Одним из следствий вышесказанного является следующая логика. Следует максимально избегать ситуаций, когда заказчик навязывает интегратору проектную технологию, по которой нужно делать проект. Если интегратор не работает с такой технологией и невозможно корректно адаптировать привычно используемую им технологию под требуемый состав документации, то будет нарушено правило «смыслового инкремента» и часть артефактов будут обладать околонулевой ценностью. Хотя ресурсы на их подготовку будут потрачены.
Про толерантность
Есть расхожая фраза – «Наши ошибки – это наши точки роста». Звучит хорошо. И работает тоже хорошо. Главное придерживаться двух максим.
Максима первая. Стопроцентная толерантность к ошибкам. Тут все просто и понятно. Про это написано куча умных книг и статей.
Максима вторая. Без которой соблюдение первой максимы не имеет никакого смысла. Нулевая толерантность к повторению ошибок.
Именно при соблюдении обоих максим, становится справедливой другая расхожая фраза – «Сотрудник становится ценнее для работодателя на стоимость совершенной ошибки».
Про строительный материал
Почему внутри одних интеграторов регулярно вырастают функциональные архитекторы и изредка технические? А внутри других, наоборот, технические архитекторы растут как грибы после дождя, а вот с ростом функциональных есть проблемы? Для ответа на эти вопросы нужно разобраться из кого вырастают функциональные архитекторы, т.к. трек роста в технические архитекторы в целом линеен. Отложим в сторону исключения в виде «уникальных» историй «уникальных» людей и попробуем выделить систему. У нас есть два источника кандидатов в функциональные архитекторы – «программисты» и «аналитики».
Посмотрим на усредненный профиль «программиста». Скорее всего это человек с техническим образованием. Скорее всего с уклоном в «математику». Скорее всего с хорошим уровнем абстрактного мышления.
Посмотрим на усредненный профиль «аналитика». Скорее всего это человек с гуманитарным образованием. Скорее всего с уклоном в «экономику». Скорее всего с хорошим уровнем коммуникации с бизнесом.
Видится, что базовый набор навыков у «программистам» более «системный» и позволяет им вырасти в функциональные архитекторы с большей вероятностью, чем «аналитикам». Хотя такой вывод и может сперва показаться контринтуитивным.
А теперь посмотрим на корпоративную культуру и проектную технологию интеграторов.
Корпоративная культура в принципе может не предполагать роста функциональных архитекторов из «программистов». Развитие «программистов» строится исключительно вокруг технического трека - девопс, код-ревью, континиус интегрейшн и прочие интересные и полезные компетенции.
Что касается проектной технологии, то тут важно, кто в проектной команде занимается вопросами проектирования доработок (функциональные дизайны расширений, технические проекты и аналогичные проектные артефакты). Если проектируют «аналитики», то тогда они главные кандидаты на рост в функциональные архитекторы. Но при этом, как описано выше, стартовая позиция у них хуже, чем у «программистов». Если же проектируют «программисты» и плюс к этому соблюдают высокую культуру самостоятельного тестирования, то в этом случае именно «программисты» становятся главными кандидатами на рост в функциональные архитекторы. И тут уже все зависит от личной мотивации специалиста. Хочет ли он оставаться в техническом треке развития и расти в технические архитекторы, или же повышать уровень «бизнесовости» в треке развития и расти в функциональные архитекторы.
В заключение хотелось бы обсудить, а возможно ли комбинировать подходы и с одинаковым успехом растить как технических, так и функциональных архитекторов? В теории, конечно, возможно. Но если имплементировать в корпоративную культуру оба трека развития «программистов» видится вполне реальной задачей, то сбалансированное применение двух проектных технологий с принципиально разным подходом к проектированию доработок в одном бизнес-подразделении, видится не совсем целесообразным, т.к. усложняет комплектование проектных команд и ухудшает ритмичность производства проектов. И если интегратор в состоянии на системном уровне растить один класс архитекторов (что уже является огромным конкурентным преимуществом), то логичнее видится добирать архитекторов недостающего класса за счет наема с рынка.
Про меру успешности
Архитектор меряет свою успешность созданными системами. Менеджер проекта меряет свою успешность подписанными актами. Здесь можно было бы поискать противоречие, но его нет. Разность мотиваций и психотипов порождает разнообразие. Разнообразие порождает устойчивую экосистему. Устойчивая экосистема порождает успешные проекты.
Про грейды
Если вы не отягощены задачами линейного менеджмента, наема и мотивации персонала, то при формировании проектной команды, а главное при распределении задач внутри нее, допускается пользоваться следующей системой грейдов – консультанты делятся на ведущих и ведомых. Более сложные системы – от лукавого. Даже классическое деление на джунов, мидлов и синьоров – это про логику «компетенции копятся линейно, фиксируются скачкообразно», а не про способность выполнения задач на проекте.
Про компетенции
Важно разделять компетенции как таковые и способность их реализовывать. Допустим есть два штангиста – Вася и Петя. На тренировках Вася жмет от груди то 90, то 95. А вот Петя стабильно 100. Но приходит время соревнований, Вася собирает волю в кулак и выжимает 100. А Петя ловит мандраж и останавливается на весе 95. Так вот, работа на проектах внедрения – это про соревнования, а не про тренировки. При прочих равных, лучше брать в команду способного выдавать результат Васю, а не очаровываться компетенциями Пети.
Про толмачей
Иногда кажется, что архитекторов и менеджеров проекта корректнее называть переводчиками. Ведешь какую-нибудь «горячую» встречу с представителями разных бизнес-подразделений заказчика. Вроде все говорят об одном и том же, а понять друг друга не могут. Из-за этого и договориться не могут. Чтобы исправить ситуацию, приходится брать слово и начинать переводить. С русского на русский.
Про программистов
После того, как каменная печь была сложена, печник разводил небольшой огонь и смотрел как ведет себя дым – проверяя герметичность кладки и корректность тяги. Из вышесказанного можно сделать вывод, что культура сдачи кода на Руси была известна издревле. Но почему-то частично стерлась из генетической памяти.
