Я представляю компанию «Арт Порт», мы находимся на юге Украины и уже более 25 лет занимаемся разработкой отраслевых решений для портового и зернового бизнеса.
На слайде представлены продукты нашей компании – некоторые из них основаны на типовых конфигурациях, но есть и написанные с нуля, в том числе с использованием БСП.
Сам я работаю в сфере 1С с 2012 года – ранее был разработчиком, теперь руковожу разработкой отраслевых решений в нашей компании.
Мой доклад будет о том, как мы в компании по разработке отраслевых решений начали успешно использовать бизнес-аналитиков, и как это помогло нашим разработчикам эффективнее разрабатывать.
Функции разработчиков без аналитиков
В большинстве 1С-франчайзи программисты 1С, помимо программирования, также занимаются целым рядом дополнительных непрофильных задач.
И я сам таким был – допустим, я запланировал на день сделать много доработок в отраслевую конфигурацию. Но по факту я отвечаю на звонки клиентов, провожу показ какой-то системы, сдаю какую-то задачу и т.д.
Получается, что есть множество факторов, которые могут отвлекать разработчиков от их основной обязанности – от разработки.
И раньше у нас действительно была проблема:
-
Наши программисты 1С были не чисто разработчиками, а выполняли всю работу, помимо программирования.
-
Помимо программистов, у нас всегда была линия консультации от отдела сопровождения. Мы изначально занимались типовыми решениями 1С, потом у нас образовался отдел отраслевых решений. Поэтому линия консультации оказывала помощь по типовым решениям, а по отраслевым решениям консультировали разработчики, программисты. Потому что именно они начинают писать конфигурацию с какой-то отраслевой задачи, они же ее внедряют, они же ее поддерживают. А научить линию консультации отраслевым решениям времени особо никогда не было.
-
В результате у программистов уходило время на все, кроме разработки.
Чем они занимались?
-
когда появлялся новый клиент или новая задача, надо было проанализировать требования;
-
составить текст задания;
-
принять сами задачи и обсудить их с заказчиком;
-
затем выполнить саму разработку и внедрить ее;
-
протестировать;
-
настроить;
-
сдать работы;
-
плюс заказчики звонят напрямую программистам и выясняют, почему что-то может не работать;
-
в конце разработчики еще составляют документацию по разработкам.
В итоге мы насчитали 10 дополнительных функций, помимо программирования. Было понятно, что у разработчиков не хватает времени на разработку.
Но при этом разработка – это дефицитный навык.
Конечно, быть на линии консультации и общаться с клиентами – тоже не у всех хорошо получается. Но на то, чтобы получить нормального, качественного разработчика, который знает правила разработки и типовые конфигурации, уходит несколько лет, тяжело найти таких людей.
Каждый должен заниматься своим делом. Потому мы решили, что неэффективно использовать разработчика на дела, которые могут выполнять другие люди.
Я не хочу сказать, что сотрудники, которые не занимаются разработкой, менее эффективны. Нет, просто каждый должен заниматься своим делом. Если программист-разработчик хорошо умеет программировать и разбирается в 1С (и не только), то он должен тратить свое время преимущественно на это. А другие дела, которые больше касаются работы с клиентами, должны делать отдельные люди.
В результате мы пришли к выводу, что нам нужны аналитики.
Это было примерно пять лет назад – тогда как раз появилась тенденция на появление в мире ИТ отдельных специалистов-аналитиков – для веб-разработки, разработки на Java, на Си и т.д.
Мы пришли к выводу, что у аналитиков должны быть те же самые функции, что на предыдущем слайде у разработчика, только без разработки. Они должны заниматься всем, что касается проектов и работы с клиентами, кроме программирования.
В идеале даже вредно, если аналитик будет программистом. Он должен поверхностно знать основы конфигурирования, он должен понимать (для оценки работ), можно ли сделать ту или иную вещь, как это примерно будет выглядеть в архитектуре. Но он не должен уметь самостоятельно заходить в конфигуратор и что-то кодировать и поправлять.
Откуда брать аналитиков
Возник вопрос: «Откуда брать аналитиков?» Для этого есть три источника (мы из них использовали два).
-
Первый – специалисты клиентов. Найти аналитика по какой-то конкретной отрасли – сложнее, чем найти аналитика по типовой конфигурации «1С:Бухгалтерия» или «1С:Управление торговлей». Мы брали специалистов от клиентов. Например, есть порт, элеватор, на нем работает начальник группы учета (главный учетчик, который ведет движение грузового транспорта). Если он увольняется от клиента и ищет работу, ему можно предложить поработать аналитиком, внедрять наши отраслевые решения.
-
Второй вариант – сделать аналитика из своих сотрудников. В Украине несколько лет назад запретили продавать продукты 1С для государственных предприятий. В это время резко упала нагрузка по внедрению типовых решений. Тем не менее, у нас было много консультантов по внедрению таких типовых решений, и чтобы обеспечить их работой, мы выделили лучших и подготовили из них аналитиков по отраслевым решениям.
-
Есть третий вариант, но мы его пока не использовали, – найти новых сотрудников на роль бизнес-аналитика. Это люди, которые раньше работали на такой же должности аналитика или студенты, новые сотрудники из сферы ИТ, которые хотят попробовать себя в этой роли. Тогда их надо отправлять на курсы аналитиков 1С, обучать своим продуктам. Из них тоже могут получиться хорошие работники.
Взаимодействие разработчиков и аналитиков
Рассмотрим, как мы в результате организовали взаимодействие разработчиков и аналитиков.
Раньше все перечисленные функции выполнял разработчик, а теперь мы их разделили на две части – аналитик берет на себя всю работу с клиентом, а разработчик в идеале контактирует с клиентом минимально. Но бывает, что разработчику нужно связаться с заказчиком вместе с аналитиком – уточнить какие-то технические моменты, которые аналитик не всегда может знать.
Но в целом порядок работы теперь такой:
-
Когда возникает новая задача, например, доработать какой-то документ, аналитик связывается с клиентом, собирает у него функциональные требования и обсуждает их с разработчиком.
-
Оценку задачи выполняют аналитик с разработчиком совместно. На курсах аналитиков 1С говорят, что аналитик должен сам примерно оценивать задачи, но я считаю, что аналитик может ее прикинуть только примерно, если он опытный, особенно если в прошлом он был программистом. Но потом он все равно занимается оценкой вместе с разработчиком. Разработчик, даже скорее архитектор, анализирует задачу, и они вместе составляют оценку данной задачи.
-
Далее составляется текст задания, аналитик прорабатывает с заказчиком все детали, уточняет требования, рисует бизнес-процессы, готовит эскизы экранных форм. Текст задания согласовывается и с разработчиком, и с клиентом.
-
Затем аналитик ставит задачу разработчику в бэклог.
-
Разработчик выполняет задачу, тестирует ее сам и передает на тестирование аналитику.
-
На этом этапе может также использоваться отдельный тестировщик или автоматические тесты. Но, поскольку аналитик является ответственным перед заказчиком за сдачу работы, он должен провести некоторое ручное сценарное тестирование, чтобы убедиться, что в целом задача правильно выполнена и удобна пользователям.
-
У нас аналитик чаще всего занимается обновлением рабочей базы. Если только это не тот случай, когда нужно больше, чем простое обновление. Т.е. разработчик говорит аналитику, как обновить рабочую базу и что в ней нужно донастроить.
-
Затем аналитик сдает базу клиенту, в ответ получает замечания на ошибки и обменивается ими с разработчиком до того момента, пока клиент не примет задачу окончательно.
-
Разработчик, в свою очередь, эти ошибки исправляет.
-
Также аналитик может заниматься дополнением пользовательской документации. Но у нас этим занимается отдельный технический писатель. На аналитика мы задачу дополнения пользовательской документации обычно не ставим, но теоретически он может такое выполнять. Если вы не разрабатываете тиражные отраслевые решения, то, наверное, в отдельном техническом писателе нет смысла, и аналитик тоже может этим заниматься. Это будет подготовка документации к конкретному проекту.
Преимущества работы с аналитиками для разработчиков
Когда мы начали привлекать отдельных аналитиков, то увидели следующие преимущества для разработчиков и в целом для фирмы.
-
Разработчики стали в основном разрабатывать. Они, конечно же, продолжают консультировать тех же аналитиков, но, по большей части, они тратят время именно на разработку.
-
Разработчики не пугают клиентов. Это несколько провокационная фраза, поэтому объясню, что я хочу сказать. Часто бывает, что опытные разработчики со стажем больше 10 лет, при постановке задачи могут пугать клиента – они начинают предугадывать, к чему эта задача приведет, что она впоследствии усложнит учет и т.д. Они начинают давить на клиента, требовать максимально детализированную проработку всего, чего можно. Это приводит к тому, что плановые часы завышаются, и клиент пугается, что даже небольшая задача на 10 часов теперь разрослась до полноценного техзадания в 100 часов. Тут нужна золотая середина, и аналитик – это тот посредник, который должен выслушать мнение разработчика, к чему это может привести (какое-то изменение функциональности), и согласовать это с клиентом, но более аккуратно, чем это сделает разработчик.
-
При таком посредничестве разработчики меньше нервничают. У тебя на носу дедлайн, ты не успеваешь, а тебе еще параллельно звонят клиенты – с кем-то что-то надо согласовать, кому-то что-то надо сдать – такое переключение между задачами нервирует разработчиков.
-
Поскольку переключение между задачами исчезло, разработчики стали вырабатывать больше часов. На митапе по инструментарию руководителя проекта я рассказывал про нашу систему учета фактической загрузки сотрудников и то, как она нам помогла найти скрытые часы. Когда мы освободили разработчиков от общения с клиентами у нас выработка увеличилась еще больше – примерно в 1,5 раза – потому что и разработчики стали больше вырабатывать, и сами аналитики стали приносить дополнительные часы.
-
Еще одно преимущество – клиенты стали более довольны работой с компанией. Согласитесь, программисты – это люди другого психотипа. Есть множество разработчиков, которые умеют хорошо общаться с клиентами, но обычно аналитики более коммуникабельные люди, они лучше общаются с заказчиками. Если сравнить с отраслевыми решениями при продажах, например, вредно, когда разработчик программы пытается ее самостоятельно продать. Потому что, когда он кому-то рассказывает про систему, он помнит, сколько внутри технического долга, сколько багов, знает, чего система не может, хотя должна была бы. И у него портится продажа. Примерно то же самое, когда идет приемка-сдача работы. А аналитик сдает ровно то, о чем он договорился с клиентом, и он не задумывается, как это сделано внутри. Разработчик даже мог это сделать с каким-то техническим долгом, но аналитик об этом может даже не знать. Поэтому в целом приемка-сдача работы получается лучше.
-
Отсюда следует, что клиенты понимают, за что платят. У нас была проблема, когда клиенты не понимали, за что платить разработчику, помимо самого программирования. Т.е. ты оценил задачу в 20 часов, а потом ты начинаешь ее тестировать, документировать, обновлять рабочую базу, объяснить все клиенту. Это в некоторых случаях может отнимать столько же времени, сколько само программирование. И приходится сразу оценивать задачу не в 10 часов, а закладывать туда и сопутствующие работы. И иногда клиенты спрашивают, почему такой простой отчет занимает так много времени. Начинаешь им объяснять, сколько часов куда уходит, но они не понимают, что эти часы нужно оплачивать – они думают, что это все должно входить в работу разработчика. А если эту работу выполняет аналитик, клиенты охотнее принимают факт, что есть отдельный сотрудник, консультант, и что теперь платить за квалифицированную работу уже нужно двоим сотрудникам.
-
Еще один плюс, который мы заметили, – задачи тестируются лучше и сдаются комфортнее для клиента. По поводу тестирования, я думаю, это понятно, что, кроме разработчика, тестировать должен еще кто-то – поэтому аналитик в данном случае выступает как сценарный тестировщик.
-
И разработчики не взаимодействуют с клиентом – это причина того, что они не нервничают, и клиенты более довольны коммуникабельной работе аналитиков с ними.
Недостатки работы с аналитиками для разработчиков
Конечно, есть и определенные недостатки в таком взаимодействии.
-
Когда мы берем отдельного аналитика на работу, ему надо находить постоянную загрузку, а постоянный поток клиентов бывает не всегда, бывают какие-то спады – периоды, когда меньше активности. Нам не всегда удается занять аналитика настолько, чтобы он заработал свой оклад. Поэтому его приходится загружать какими-то смежными задачами.
-
Еще один минус – не все клиенты согласны оплачивать такие сопутствующие работы. Тут уже больше зависит от менталитета, но надо доказывать клиенту, что такие работы необходимы, без них сама разработка смысла не имеет.
-
Еще одна проблема, с которой мы столкнулись, правда, чисто в отраслевых решениях, – поскольку и программист, и архитектор, и владелец продукта разрабатывают это решение изначально, они могут знать предметную область лучше, чем аналитик. Поэтому сам разработчик может быть лучшим аналитиком. Но опять же: он в первую очередь программист. Разработчик может консультировать аналитика по некоторым вещам, но аналитик все равно должен быть отдельный.
-
Еще один момент – изначально некоторые наши разработчики негативно восприняли совместную работу с бизнес-аналитиками, потому что им нравилось общаться с клиентами и лично сдавать работы, и они были согласны тратить на это время, хотя и понимали, что разработка при этом страдала. Такие разработчики ревностно восприняли передачу части работы отдельным аналитикам, потому что считали, что мы «забираем у них хлеб». Но очень скоро все выровнялось, они поняли, что так работать эффективнее. Негатив пропал.
Как мы построили работу с бизнес-аналитиками
На данный момент в нашей компании есть два бизнес-аналитика.
-
Первый – аналитик от клиента, портового оператора. Это компания в порту, которая занимается перевалкой из вагонов и автомобилей на морские суда и, наоборот, из судов на наземный транспорт. 6 лет назад мы внедряли программы для портового оператора. Там был аналитик, руководитель проекта со стороны заказчика. Потом он уволился из компании, и мы его подключили сначала к нескольким проектам в качестве консультанта. Нам понравилось, как он занимался приемкой-сдачей задач, и мы ему предложили штатное место, чтобы он занимался бизнес-анализом.
-
Второй аналитик – наш бывший сотрудник, который занимался консультацией на линии поддержки типовых решений (торговля, ERP, бухгалтерия). Когда загрузка по этим направлениям упала, мы обучили работника отраслевым решениям, навыкам приемки-сдачи работ и тестирования, и из него тоже получился неплохой бизнес-аналитик, поскольку на этот момент он уже хорошо знал работу с 1С и имел опыт общения с клиентами.
Оба работника выполняют постановку задач, их проверку и приемку-сдачу клиентам, и какие-то функции по руководству проектами – например, следят за выполнением задач в срок.
Частично их часы мы выставляем клиентам в явном виде – как консультации и бизнес-анализ. А часы на тестирование задачи, приемку-сдачу, документирование мы на этапе планирования работ включаем в часы разработки по конкретному пункту спецификации.
В итоге разработчики стали спокойнее, а клиенты понимают, за что платят.
У разработчиков в 1,5 раза увеличилась выработка именно за счет разработки, появились дополнительные часы, которые зарабатывают сами аналитики.
Все проекты сдаются успешно, а некоторые – особо успешно, благодаря именно аналитикам.
Аналитики у нас в компании появились как раз в тот момент, когда отдельные проекты были в критическом состоянии: разработчики не успевали принимать-сдавать работы и одновременно разрабатывать. Клиент торопил и давил на разработчиков психологически – из-за этого назревали конфликты, появлялась злость на клиента. Как раз в этот момент мы подключили аналитика – посредника, который свежим взглядом окинул проект, обследовал его заново и смог вовремя сдать. За счет этого проект был спасен и успешно завершился.
Мой совет – если вы видите, что разработчики тратят много времени на сопутствующие работы, а не на разработку, есть смысл подключить аналитиков, которые смогут выполнять эти функции.
Вопросы
Какое должно быть количество аналитиков на какое количество программистов?
Пока еще у нас мало опыта, чтобы определить, какое точно должно быть соотношение. Но мне кажется, что количество аналитиков должно быть пропорционально не количеству разработчиков, а клиентов. Тут больше вопрос – сколько один аналитик может вести задач.
У нас, по сути, три аналитика, я тоже по некоторым проектам выступаю аналитиком. Но, в целом, на каждое отраслевое направление (зерновое и железнодорожное) есть по одному аналитику.
Если ориентироваться по клиентам, то один аналитик способен вести примерно пять крупных, серьезных клиентов, которым нужна постоянная поддержка.
С кем происходит согласование технического задания – с обычным разработчиком, тем, который будет его выполнять, или с ведущим разработчиком на проекте или в группе?
Согласование происходит с ведущим разработчиком по отраслевому направлению. У нас нет отдельного архитектора или владельца продукта, у нас эти роли соединены. И аналитик согласовывает техзадание с руководителем проекта. Этот же человек является чаще всего владельцем продукта.
Пока у нас не такой большой штат, чтобы было несколько ведущих разработчиков по одному направлению. Поэтому согласование происходит не с конкретным исполнителем, а с руководителем разработки. А дальше он сам распределяет работы по подчиненным разработчикам.
Upd. В 2022 году мы ввели роль “Технический руководитель проекта” - на данный момент первоначально именно он участвует в разработке ТЗ и только при необходимости консультируется с ведущим разработчиком по отраслевому решению. Такой подход позволяет повысить количество проектов и скорость оценки задач.
*************
Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Бизнес-аналитик. Роль в команде, компетенции, инструментарий". Больше статей можно прочитать здесь.
