Я рассмотрю тему разрешения противоречий и попробую поделиться своим опытом: как нам разрешить конфликт, когда задач хочется делать больше, а рук, которые могут эти задачи выполнять, не всегда хватает. Каким образом перераспределить задачи в команде разработки, чтобы это оставалось эффективным, а продукт выходил качественным?
Во-первых, пройдемся по контексту, по типичному распределению ролей в команде, которые специфичны для 1С-разработки. Поговорим, какие ключевые функции мы закладываем в человека, выделяя его на отдельную роль, на самостоятельную работу по этой роли.
Далее разберем пространство для маневра: какие еще есть задачи в команде, которые повышают эффективность, повышают качество продукта, и при этом их можно как-то варьировать, распределять между основными ролями.
И поговорим о выгоде и рисках такого перераспределения. В частности, когда новые функции появляются у аналитика, как это может повысить эффективность команды, а когда добавляет дополнительные риски.
В фокусе нашего контекста мы держим цель повышения эффективности команды разработки. Команда разработки в большинстве случаев имеет задачу выкатывать фичи для продукта или для проекта, который она внедряет. При этом не снижая качество. То есть фич становится больше, но качество остается на том уровне, который согласован с заказчиком, и при этом не увеличивается технический долг.
Не стоит выстраивать организацию разработки таким образом, чтобы сейчас мы делали 10 фич за условную неделю, а через год, накопив технический долг, могли делать не больше одной – просто потому что больше уже не разогнаться.
Роли в команде разработки
Какие роли рассматриваем в команде разработки? В общем и целом есть разработчик, который руками пишет функциональность. Есть аналитик, который общается с пользователем, выявляет требования, формулирует задачи для разработчика. Есть тестировщик, который контролирует качество. И во главе этой картинки – менеджер проектов, который каким-то образом управляет работой.
Здесь сразу оговорюсь: мы не говорим о том, что на каждую роль в каждой команде обязательно должен быть выделен отдельный человек. Роли и сотрудники могут сочетаться разными способами. Например, один сотрудник может владеть несколькими ролями. Либо, если это большая команда, одну роль могут выполнять несколько сотрудников.
При этом стереотипные сочетания в командах 1С-разработки – это, во-первых, разработчик-одиночка. Он достаточно знает бизнес, получает задачу от заказчиков или от менеджеров, которые общаются с клиентами, самостоятельно ее исследует, делает, разрабатывает, обеспечивает качество и объясняет заказчику, как ему теперь с этим жить. То есть замыкает на себе полный цикл.
Есть переходный момент – разработчик плюс подмастерья, когда основная функциональность, роль аналитика, роль разработчика, роль инженера QA все равно остаются на одном человеке. Такой универсальный разработчик, но он уже научился делегировать часть рутинных задач.
Например: «Ты сделай протокол созвона, ты подготовь макет печатной формы, ты, как junior-разработчик, напиши эти куски подмодулей, которые я выделил и вписал в общую архитектуру. А кто-то автоматизируй автотест или пощелкай по готовому чек-листу, согласованному с клиентом. Либо подготовь текстовую инструкцию». Выделенных людей именно на самостоятельную работу в ролях еще нет, но уже появляется разделение труда для повышения эффективности.
Следующее, на чем мы сфокусируемся в рамках статьи, – это разделение аналитика и разработчика. То есть ситуация, когда у нас есть человек, выделенный самостоятельно на роль аналитика. Он закрывает свой пул задач, у него выделена своя ответственность. И есть разработчик, у которого тоже есть своя ответственность.
Безусловно, в крупных командах добавится менеджер, который будет делать документарную обвязку и управлять взаимодействием, добавится QA, который будет отвечать за качество и контролировать. Но на распределение задач внутри связки разработчика и аналитика это будет влиять опосредованно. Возможно, часть задач из этой связки просто уйдет, поэтому мы можем спокойно сфокусироваться именно на ней.
Еще раз: фокусируемся именно на связке разработчик – аналитик. И часть дополнительных функций, которые мы будем дальше рассматривать, в более крупной команде в этой связке будут отсутствовать. Предположим, что у нас есть условные два человека и у них подмастерья.
Ключевые функции аналитика и разработчика
Попробуем разбить ключевые функции: в чем задача развития продукта, разбитая между этими двумя условными людьми.
Ключевые функции аналитика – выявить требования к IT-продукту и сопроводить их реализацию. То есть нам нужно сходить к заказчику, изучить нормативно-правовую базу, которая, возможно, регулирует нашу разработку. Нам нужно посмотреть, как в реальности устроена работа компании, затем описать требования, донести их до разработчика.
Аналитик участвует в процессе коммуникации в команде: если есть вопросы, как сделать, если есть технические ограничения, с которыми разработчик к нам пришел, их нужно как-то разрешать, переговариваться с заказчиком, возможно, осуществлять авторский контроль. То есть постепенно наблюдать за тем, что реализует разработчик, и проверять, соответствует ли это тому, что я согласовал с бизнесом, чтобы в процессе не возникло сильного разрыва в суждениях.
Ответственность, которую несет аналитик при таком разделении, – это продукт, попадающий в потребности заказчика. Заказчик не должен получить то, что совсем промахивается мимо его ожиданий. Заказчик действительно должен повысить эффективность своей работы или закрыть свою потребность в автоматизации с помощью тех новых функций, которые принесла ему команда разработки.
Ключевые функции разработчика. Разработчик берет на себя инженерную сторону вопроса. Основная цель – подготовить работающий, инженерно грамотный, оптимальный, стабильный механизм в соответствии с теми требованиями, которые принес аналитик.
То есть выбор способа реализации, выбор алгоритма, архитектура, непосредственно разработка, написание программного кода в соответствии со стандартами и его оформление – в соответствии с внутренними стандартами или стандартами, общепринятыми профессиональным сообществом.
И еще – уточнение в процессе разработки. Если мои инженерные возможности сильно выходят за рамки оценки для реализации того или иного требования или, в принципе, требование нереализуемо на этих технологиях за разумный срок, нужно сказать об этом аналитику: «Вот здесь у нас проблемы, противоречия, давайте передоговариваться».
Ответственность, которую здесь несет разработчик: продукт работает стабильно, без ошибок, соответствует принятым стандартам. Он выпущен и дальше ведет себя хорошо, имеет запас прочности при увеличении нагрузки и так далее.
Дополнительные функции
Дальше у нас есть набор дополнительных функций, которые появляются в процессе рождения продукта. Они тоже повышают эффективность команды, но по ним уже можно варьировать, кто именно будет их делать. Подробнее остановимся на каждой из них.
Исследования
На этапе исследования наша задача – собрать контекст вокруг решаемой задачи. Есть базовые задачи, которые очевидно идут на аналитика: интервью, изучение документации, изучение нормативно-правовой базы.
Но дальше появляются задачи другого типа. Мы можем исследовать, например, как нужная логика на текущий момент реализована в нашем продукте, которым автоматизирована компания, если мы хотим его дорабатывать.
И здесь вопрос: я могу как аналитик сходить к разработчику, попросить его рассказать, посмотреть программный код, посидеть со мной. Но если я умею работать с Git-репозиторием, если умею открывать конфигуратор, то в общем и целом я и сам могу посмотреть, изучить какие-то алгоритмы, если знаю основные паттерны чтения кода.
Читать код несколько проще, чем писать. Тем более мы помним, что работаем в концепции предметно-ориентированного программирования. В программном коде, если он хорошо написан, будут прослеживаться и термины прикладной области, и общая логика прикладной области. Поэтому оттуда можно вытащить смыслы, если не бояться.
Это может быть задача, связанная с анализом накопленных данных. С одной стороны, можно прийти к разработчику и попросить что-то собрать, выгрузить, написать отчеты. С другой стороны, если аналитик владеет консолью запросов, языком SQL, умеет использовать различные BI-механизмы, например 1С:Аналитику, подключенную к базе, то он может самостоятельно извлечь эти данные, проанализировать их и использовать при выработке функциональных требований. Это же касается изучения исходного кода, если это необходимо, в части использования модулей и совместной работы некоторых механизмов.
Прототипы
Когда мы разрабатываем функциональные требования, для того чтобы заранее убедиться, что предложенное решение решит задачу заказчика, очень эффективно использовать прототипы.
Прототипы могут идти от макетов. В принципе, макеты аналитик, скорее всего, сможет накидать без разработчика. Это может быть Paint, Figma, любые инструменты прототипирования. Возможно, даже в конфигураторе можно накидать формочки, хотя это чуть сложнее, нужно знать чуть больше. Но это базовый навык.
С другой стороны, это может быть задача по разработке заглушки API, если мы проектируем какое-то интеграционное взаимодействие. Это может быть задача по разработке MVP.
Условно, у нас есть задача распределить себестоимость между статьями затрат по какому-то хитрому алгоритму разными способами. Если заказчик сначала пробует объяснить это нам на пальцах, мы можем взять Excel, сделать формулу в Excel как промежуточный инструмент.
Либо, если мы умеем немного программировать, можем сделать внешнюю обработку, запускающуюся в пустой базе, и попробовать смоделировать это распределение, чтобы дать заказчику заранее пощелкать. А если он поймет, что хочет не совсем это, что у него есть другие пожелания, он нам об этом скажет, мы на ходу подкрутим и вернемся к нему через полдня с новой версией.
Таким образом мы быстро проверяем гипотезу и убеждаемся, что сформулированные функциональные требования к системе попадают в потребности заказчика до того, как разработчик отвлечется от своей задачи, потратит много времени и вернется к нам через неделю с в целом более грамотно написанным механизмом распределения, который может оказаться не попадающим в те самые потребности.
Тестирование
Если мы работаем в команде из двух человек и у нас нет выделенного QA, то разработчик сам за собой тестирует плохо. Как бы то ни было, сложно бороться с некой зашоренностью взгляда, когда ты реализуешь большую функциональность: глаз замыливается.
Безусловно, есть различные методики, которые с этим борются: автоматизированное тестирование, разработка через тестирование и так далее. Но это сложно, это нужно внедрять отдельно.
По классике разработчик сделал – все равно аналитик или кто-то другой проверил. Если нас двое, то аналитик неизбежно проверяет.
Это может быть ручное тестирование – самое поверхностное, в интерфейсе, для которого не нужно дополнительных технических навыков. Это может быть проверка API, и здесь уже важно владеть инструментами, например Postman или SoapUI, чтобы хотя бы извне дернуть тот или иной внешний программный интерфейс: HTTP-сервис или веб-сервис.
И это может быть автоматизация тестирования. Автоматизация тестирования очень хорошо работает на регрессе. Например, у нас есть механизм, который должен формировать сложные печатные формы по каким-то запутанным правилам. Выверять каждый раз руками, что 100 печатных форм не поменялись и продолжают соответствовать нашим требованиям, – это очень трудоемкая задача. Но эта очень трудоемкая задача автоматизируется буквально за несколько дней на фреймворках тестирования, а дальше проверяется, пока мы ходим попить кофе.
Разработчик выкатил нам новую версию. Мы запустили ее без всяких CI/CD-контуров, без сложной настройки: просто в интерфейсе нажали кнопку play, сходили попить чай, через 10 минут вернулись и увидели, что в этих двух макетах из ста поехало расположение, в таблице появились дополнительные строки или формулировки перестали соответствовать необходимым. И это тоже сильно улучшает качество.
Документация
Далее – написание документации. Непосредственно написание – это понятная задача.
Есть отличная парадигма Docs as code, когда мы не пишем документацию в виде Word-файлов или статей в Confluence, а пишем ее в формате Markdown, в машиночитаемом виде. Затем версионируем через Git, и когда эта документация идет пользователю, у нас формируется хорошая база знаний с удобным поиском с помощью специальных средств сборки. Например, таким образом делается документация по технологии 1С:Предприятие.Элемент.
Это позволяет легче управлять документацией. Плюс, если разработчик использует Git-репозиторий, это позволяет хранить документацию рядом с исходным кодом и делать одновременные релизы. То есть мы выпустили релиз новой версии нашего продукта, и вместе с этим релизом у нас синхронно опубликовалась новая версия документации. Нет никаких разрывов по времени.
Еще один отличный инструмент для поддержки документации в актуальном состоянии – автогенерация. Если у нас есть слой пользователей, которым важно, чтобы каждая кнопка была на месте, это может быть полезно.
Я встречался с такими пользователями: есть скриншот документации, есть интерфейс, и одна кнопка, причем даже не связанная со сценарием, просто расположена в другом месте. Или разделы поменялись местами – и пользователи уже начинают путаться.
Есть механизмы автогенерации, например через фреймворк Vanessa Automation, когда мы выпустили новую версию, запустили скрипт и на выходе получили либо ту же документацию в Markdown или PDF, либо озвученное видео о том, как пользователям работать.
Это позволяет для широкого круга не очень квалифицированных пользователей поддерживать документацию, которая заменит им обращения в техподдержку. Они смогут быстро прийти, разобраться и решить свою задачу.
Сопровождение
Когда мы выпустили новую версию, нам важно смотреть, как она работает. В первую очередь – для того, чтобы следующие функциональные требования формулировались грамотно. И для того, чтобы, если возникают конфликты по приоритетам, мы могли аргументировать свою позицию: почему лучше эту фичу сделать попроще и попозже, а эту – получше и пораньше.
Здесь мы можем, во-первых, еще на этапе проектирования, если предполагается длительное развитие и длительная жизнь системы, сразу закладывать метрики. То есть как мы будем анализировать, как пользователи работают? Где мы это будем собирать? Возможно, предусмотрим отдельную пару регистров, где это у пользователей будет храниться, а потом запросим: «Вот профиль твоей работы. Значит, вот это для тебя важно, а это не очень».
Дальше важно уметь анализировать эти логи через журнал регистрации, через свои внутренние механизмы, через какие-то сервисы сбора метрик, возможно, через замеры времени, которые есть в БСП. Они косвенным образом позволяют в том числе собрать информацию о том, какую ключевую операцию пользователь использует чаще.
Например, мы делаем несколько документов, несколько отчетов. Мы заранее сказали разработчику: «Используй типовую возможность библиотеки стандартных подсистем считать, сколько времени выполняется та или иная ключевая операция». И автоматически получили ответ на вопрос, насколько часто пользователи используют эту ключевую операцию.
Далее важно уметь эту информацию достать, проанализировать и сделать выводы. В некоторых сценариях мы можем вообще записать работу пользователя – с техническими ограничениями – и попробовать проанализировать, где он теряется, какие кнопки долго ищет и так далее.
Инструменты
Из всех этих задач складывается палитра технических навыков, которые могут присутствовать у аналитика.
Они выстроены от самых нетехнологичных, близких к интуитивному пониманию: Figma, различные нотации – они уже менее интуитивны, но не заставляют глубоко погружаться в инженерию и программный код. Это офисные пакеты, системы хранения знаний и так далее.
Посередине – инструменты, которые уже требуют зацепиться за некую техническую экспертизу, но при этом мы еще не сильно погружаемся в разработку. Это умение настраивать варианты отчетов с помощью системы компоновки данных платформы, использовать универсальные отчеты, которые встроены практически во все типовые решения и наследованы из библиотеки стандартных подсистем.
Это возможность изучить данные с помощью консоли запросов, которые не выведены в интерфейс. Ограничение универсального отчета в том, что мы можем получить данные только из одной таблицы или проваливаясь по ссылкам. Консоль запросов на честном SQL уже позволяет делать более сложные соединения.
Это умение анализировать журнал регистрации, умение автоматизировать тестирование или формирование документации через Vanessa Automation как фреймворк автоматизации.
И финальный уровень, где мы уже заходим в зону разработчика, – это умение читать исходный код, умение использовать отладку для изучения принципа работы программы: что приходит в этот алгоритм, что уходит на выход.
Это умение использовать инструменты вызова API, такие как Postman, SoapUI, инструменты перехвата трафика, сырой SQL, если мы интегрируемся с системами вне 1С, которые хранят данные непосредственно в SQL, и нам нужно как-то их изучать, чтобы продумывать интеграцию.
Здесь нет очевидного и единственно правильного решения, какой набор этих инструментов правильно знать аналитику. Возвращаемся к мысли, которая была в начале: нам важно повысить эффективность команды.
Если у аналитика, который находится в зеленой зоне, хватает задач, если разработчики загружены, он загружен, и разработчики не являются тем самым бутылочным горлышком, то двигаться вправо нам, наверное, не нужно.
Но если есть противоречия в приоритетах, когда, с одной стороны, разработчик должен делать текущую фичу, а с другой – у нас стоит проектирование или мы не можем принять хорошее решение по проектированию, потому что нам не хватает проанализированных данных, потому что мы не понимаем до конца, как работает текущая версия, то в этом случае сдвинуться в сторону технических компетенций, в сторону роли разработчика, и получить навыки для самостоятельного поиска ответа в исходном коде и накопленных данных будет достаточно полезно.
Где команда теряет эффективность?
С точки зрения эффективности, где команда может ее терять?
Это может быть низкая квалификация исполнителя. Например, аналитик начал разрабатывать, при этом разрабатывает достаточно плохо, это его первая рабочая задача в этой роли.
Это может быть переключение контекста, когда разработчик вынужден отвлекаться. Например, разработчик делает какой-то сложный, длинный интеграционный механизм. У меня, как у аналитика, появилась потребность извлечь из системы данные. Я пришел и попросил: «Сделай отчет».
Сам отчет простейший. Разработчик его накидал в СКД за 10 минут, отдал мне внешний файл отчета. Но чтобы переключиться на мою задачу, он отвлекся от своей, потратил 15 минут, выгрузил контекст, загрузил мой. Потом мы поговорили, я ему объяснил, что мне нужно, какая табличка. Мы еще 20 минут потратили. Потом те самые 10 минут, где он готовит отчет, он его нам отдал. И потом еще минут 20 возвращается в контекст исходной задачи.
На 10 минут простой работы – потеря полтора часа плюс-минус. Переключение контекста снизило эффективность команды. А возможно, в этой ситуации я, как аналитик, мог бы 40 минут поковыряться с этим отчетом, находясь полностью в своем контексте, и получить ответ. И команда была бы несколько эффективнее.
Еще одно – транзакционные издержки. Когда мы передаем друг другу задачу, объясняем, что нам нужно, потом разработчик объясняет, как он это понял, или объясняет нам результат, а мы говорим: «Нет, это не совсем то, что мы хотим».
Любая коммуникация, связанная с передачей задачи, все равно увеличивает издержки относительно ситуации, когда задачу выполняет один человек.
Важно держать в фокусе при решении задачи такого перераспределения: что будет выгоднее – решить задачу руками менее квалифицированного аналитика, очевидным образом медленнее и не всегда полностью правильно, или вытащить разработчика из его контекста большой задачи и передать эту задачу ему.
T-shaped и M-shaped специалисты
Здесь мы подходим к способу решения, который в контексте профессионального развития обозначается терминами T-shaped и M-shaped.
Что это такое? T-shape – это когда я крутой специалист в своем фокусе, то есть одна роль у меня развита очень сильно. Например, я сильный аналитик. Но при этом какие-то смежные роли, с которыми я часто пересекаюсь, у меня развиты на уровне: могу сделать простые задачи, понимаю общие принципы, как это работает.
Например, я немного разработчик: могу писать запросы с несложным соединением, могу накидывать в конфигураторе формочки. И немного тестировщик: знаю в общем тест-дизайн, могу накликать сценарий автоматизированного тестирования на одном из имеющихся фреймворков.
M-shape – это чуть большая градация по смежным ролям. Я крутой аналитик, но и как разработчик могу что-то порешать, и как тестировщик могу что-то порешать.
В контексте T-shape и M-shape в современном мире набирает обороты искусственный интеллект. Он позволяет нам глубже опуститься в чужую роль и эффективнее решать задачи в чужой роли.
Например, если нам нужно проанализировать или обработать данные, у нас есть какая-то выгрузка из базы данных и так далее. С одной стороны, мы можем пробовать крутить это в Excel, если объем данных позволяет загрузить их в один лист Excel. Можем пробовать крутить запросы. Либо мы можем простейшим промптом в публичной нейросети сказать: «Вот у меня есть структура данных, вот такие колонки. Напиши мне скрипт на Python, чтобы преобразовать и проанализировать эти данные». Потому что на Python публичные нейросети пишут лучше.
Я запускаю этот скрипт, получаю CSV в нужном мне формате, открываю, смотрю, рисую диаграмму. Это экономия времени. При этом я вообще не знаю программирование, Python мне просто отдал результат.
Возможно, если гипотеза сложная, можно отдать этот скрипт на проверку кому-то, кто умеет читать программный код. Но если это проверка гипотезы, которую мы можем с трех сторон проверить на непротиворечивость, тогда скрипт, скорее всего, особо можно и не проверять.
Также запрос могут написать нейросети.
Если мы работаем в 1С:EDT, то можем задавать Напарнику вопросы по нашей конфигурации. Если раньше он фантазировал и придумывал, потому что не мог использовать инструменты конфигуратора, то теперь он может смотреть состав конфигурации (например, какие есть объекты метаданных), делать глобальный поиск по коду и обрабатывать результаты поиска. Ответы на вопросы, связанные с анализом того, как сейчас работает конфигурация, становятся проще, а запросы, которые он формирует в контексте конфигурации, становятся более рабочими.
То есть я, как аналитик, открываю EDT, включаю 1С-Напарника и говорю: «Мне нужно данные из этих регистров проанализировать по такой задаче». Он отвечает: «Вот тебе запрос». Я иду в пользовательский режим, открываю консоль запросов, вставляю туда этот запрос, выполняю и смотрю. Все, задача решена, я никого не дергал. Причем решена достаточно быстро, мне не нужно знать язык запросов.
Если мне нужно собрать MVP, я могу поступить плюс-минус таким же образом. Мне нужна обработка, которая работает по такому-то алгоритму. Безусловно, если я иду с этим к заказчику, мне нужно какой-то базовый навык чтения кода, чтобы это отвалидировать. Но работать с готовым программным кодом гораздо проще, чем с чистым листом.
С чистым листом без глубокого навыка разработки написать тяжело. А если алгоритм уже есть, мы его сами протестируем, какие-то формулы, возможно, поправим и дальше с ним пойдем. Сложность ниже, а по времени это быстрее.
Если нам нужно собрать референсы и аналоги, публичные нейросети здесь тоже отлично работают. Главное – не слить корпоративные секреты в публичные нейросети.
Если нам нужно подготовить документацию по текущему решению, комбинация 1С-Напарника, который знает контекст, и публичных нейросетей, которые могут готовую документацию как-то причесать в более понятный пользователям язык, тоже может сильно ускорить работу.
Риски
Какие риски важно иметь в виду при таком перераспределении задач?
Аналитик, владеющий техническими навыками и грамотно использующий современные инструменты на базе AI, может усилить команду. Но важно соблюдать баланс.
Есть риск получить универсального солдата, который и не разработчик, и не аналитик, и в общем и целом посредственен во всех ролях. Одна роль всегда должна оставаться в фокусе, и человек должен понимать, за что он несет ответственность: за наведение мостов и соответствие функциональных требований потребностям заказчика или за инженерную часть – за то, что программа работает быстро, оптимально, масштабируемо и так далее.
Есть риск передачи корпоративных данных на сторону через публичные ИИ-сервисы. Здесь нужно быть очень аккуратным. Можно максимально отжать контекст и задать абстрактный вопрос, получить абстрактный ответ и применять его для своей работы. Важно не сливать данные.
И еще один риск – размытие ответственности. Аналитик подготовил какое-то инженерное решение, MVP. Этот MVP показали заказчику, заказчику понравилось. Разработчик говорит: «О, готовая обработка, просто вставлю в конфигурацию и отдам в прод». А там неоптимальные запросы, неоптимальное хранение данных. И когда эта обработка начала работать под нагрузкой, мы получили проблемы быстродействия системы. Поэтому важно, чтобы ответственность оставалась на специалисте.
Итоги
-
Принимаем решение о развитии технологических навыков аналитика взвешенно, если это действительно необходимо.
-
Автоматизация. Там, где уместно, можем пробовать решать задачи разработчика.
-
Используем инструменты на базе искусственного интеллекта для ускорения работы. Но контролируем результаты и помним, что ответственность остается на человеке.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
