Владимир Наумов, 13/12/23
Слаженная работа подразделений компании – один из важнейших факторов ее успеха. Специалисты ИТ-отделов, ранее выполнявшие функцию технической поддержки, теперь задействованы буквально всеми подразделениями бизнеса. Эффективное взаимодействие с ИТ-отделом положительно влияет на точность, скорость и стоимость автоматизации и цифровизации компании, на ее конкурентную позицию на рынке.
Государство последовательно выстраивает взаимодействие с бизнесом посредством электронного документооборота. Бизнес также стремится удаленно взаимодействовать с контрагентами и покупателями. Повсеместно внедряется маркировка, ЭДО, электронные чеки и другие электронные сервисы. Так или иначе, в цифровизации задействованы все подразделения компании.
При этом ситуация, когда сотрудники из разных подразделений не могут договориться друг с другом, не редкость. Например, история из моей практики: бухгалтерии необходимо, чтобы отдел закупок по окончании квартала до 10 числа каждого месяца сдавал закрывающие документы за квартал, а закупкам требовалось, чтобы бухгалтерия не отвлекала их от основной работы, связанной с заключением контрактов, выбором ассортимента, регулированием цен и наценок. В свою очередь, закупки требовали от бухгалтерии вовремя оплаченных счетов, не желая слышать о том, что не хватает каких-то документов по контрагенту.
Представители подразделений не раз обращались ко мне, чтобы решить ситуацию в их пользу. И таких примеров, когда страдают коммуникации и каждый участник считает себя правым, достаточно много. В этой статье хочу рассказать о принципах успешного взаимодействия ИТ-департамента с другими подразделениями компании.
Сроки выполнения работ
Раньше я достаточно часто слышал претензии в адрес ИТ-отдела по поводу того, что они не могут указать четкие сроки разработки: вы обещали "еще вчера", "неделю назад", "в прошлом месяце", "почему так сложно при постановке задачи сразу точно сказать, через какой промежуток времени будет запущена наша автоматизация или сделана задача?"
Эту ситуацию хорошо объясняет анекдот:
– Так нечестно, ты постоянно придумываешь новые условия!
Эта история показывает, что даже простая задача, как правило, в процессе обрастает дополнительными подробностями, которые влияют на результат и на сроки.
Правило 1. Максимально детализируйте задачу
Задача "мне нужен отчет по продажам всех магазинов" изначально звучит вполне конкретно, но в процессе реализации она будет обрастать массой подробностей и в конечном итоге может выглядеть совсем иначе, например:
- В отчет по форме, который формируется к девяти часам утра и включает данные за предыдущий день, входят продажи по всем магазинам, входящим в розничную сеть, продажи по маркетплейсам, а также продажи по интернет-магазинам и другим каналам продаж.
- Отчет может быть сформирован как по товарам, так и по точкам продаж.
- Товары должны быть сгруппированы по группам, группы по категориям, категории по направлениям.
- Точки продаж могут быть сгруппированы по территориальному признаку, а также по направлениям.
- Продажи отображаются в штуках и в рублях.
- Детализация может различаться по периодам отчетности – дни, недели, месяцы, кварталы, год.
И дальше еще масса пояснений, а также информация, где брать данные по магазинам, продажам, направлениям и что делать, если по каким-то причинам данных нет.
И краткая, и развернутая формулировки задачи предполагали отчет по продажам. Как думаете, при какой формулировке заказчик будет долго конфликтовать с исполнителем на предмет того, что сделано неправильно?
Конечно, не всегда есть возможность составить подробное задание. Существует масса технических нюансов, которые заказчик может не знать. например:
- где хранятся данные, необходимые для его отчета;
- какая детализация информации существует;
- как часто точки продаж и маркетплейсы присылают информацию о проданном и др.
Как это решать? Необходимо проводить анализ перед формированием задачи, это делают бизнес-аналитики. Они осуществляют сбор требований у заказчика, уточняют подробности, общаются с представителями подразделений, чью работу затрагивает задача.
Таким образом, аналитик приходит к автору задачи и выясняет дополнительную информацию о том, какой результат ожидается, в каких сегментах должны происходить изменения. Аналитики изучают, как реализация задачи отразится на существующих процессах и информационной системе, где хранятся необходимые данные. Из полученных данных формируется техническое задание, которое после согласования с заказчиком передается разработчикам для реализации. Побочным эффектом может стать ситуация, когда заказчик, проанализировав объем изменений и инвестиционных затрат, может отказаться от реализации своей задачи.
Приведу пример изучения задачи перед ее реализацией. Заказчик захотел внести изменения в процесс. По результатам изучения задачи выяснилось, что придется вносить правки в процессы поставщиков компании, то есть наши разработчики должны были бы исправить информационную систему и цепочку движения товара у поставщика. Помимо этого, поставщику необходимо было закупить определенное оборудование для реализации задуманного. Все это позволяло немного улучшить контроль за процессом, однако экономический эффект от таких изменений никогда не был бы достигнут. В результате полученной информации заказчик предпочел отказаться от задачи.
Определите ресурсы для реализации задачи
Под ресурсами здесь подразумеваются:
- бюджет;
- свободное время сотрудников;
- необходимые компетенции;
- наличие подрядчиков и их готовность к работе;
- наличие необходимого оборудования.
Если не учесть какой-то из перечисленных факторов, то количество задач в стадии ожидания реализации будет нарастать как снежный ком. Я знаю, что у некоторых компаний данный период составляет год.
Даже если заказчики перестанут давать новые задачи, то ИТ-подразделение будет работать целый год, чтобы реализовать те, которые им уже были поручены.
Что делать в таком случае? Я бы рекомендовал проанализировать все текущие задачи и решить, нужно ли их исполнять. Критерии могут быть разными, а вариантов ответов обычно три: "да, нужно", "нет, не нужно", некий промежуточный вариант – "нужно, но сейчас не горит", "когда-нибудь позже" и т.п. Приоритетные задачи оставляем и разбиваем по срочности реализации. задачи, актуальность которых не подтверждена, сразу убираем. Задачи неопределенной категорией срочности рекомендую заархивировать и забыть. Ситуация быстро меняется, поэтому если вам это не нужно сейчас, то не факт, что понадобится в будущем, – лучше, чтобы наличие таких задач не давило на команду.
Итак, мы собрали все задачи, распределили по важности и срочности, определились с командой, которая будет их решать, и получился график выполнения работ по срокам. Затем мы информируем всех заинтересованных о графике решения задач, объяснив очередность. Пользователи при обращении получают информацию о плане, а также о том, когда их задача будет взята в работу. При необходимости мы объясняем, почему их задача не высшего приоритета. Как правило, после грамотного объяснения сотрудники понимают, почему важная для них задача будет решена только в следующем квартале.
По итогам такого подхода к работе все стороны проинформированы и спокойны. На разработчиков не давит груз нерешенных задач, заказчики не нервничают, так как знают, когда их задача будет реализована. Главное – постоянно отслеживать соблюдение ранее намеченного графика при выполнении задачи.
Не нужно брать больше задач, чем вы можете обработать на горизонте
Точный срок горизонта назвать сложно, он у всех разный. Однако подразделения должны понимать, что "в настоящий момент все операторы заняты, ваш звонок 50-й в очереди". Руководству ИТ-подразделения или компании в таком случае следует принять решение о том, как исправить ситуацию.
Когда наша компания активно расширяла штат и мы проводили много собеседований, практически все разработчики основной причиной поиска новой работы называли загруженность: задач у сотрудника больше, чем он может проработать за несколько месяцев, при этом долг, а вместе с ним и давление на сотрудника только растут. На мой вопрос о том, пробовали ли решить проблему наймом дополнительных сотрудников, соискатели отвечали, что нет. Получается, в компаниях на ровном месте создавались проблемы, которые приводили к оттоку кадров.
ИТ-отдел должен иметь статус в компании
Если в компании принято, что ИТ-отдел – это обслуживающий блок, который должен просто выполнять поручения, то в текущих реалиях полноценного взаимодействия не получится. Мне стоило больших трудов переубедить разработчиков и аналитиков в том, что есть бизнес-направление и есть ИТ-отдел. Я придерживаюсь подхода, при котором ИТ – это часть бизнеса, без которого не может работать ни одно подразделение. Мало того, ИТ-отдел может самостоятельно исполнять определенный функционал бизнеса, например вести сайт компании, отвечать за кассы самообслуживания и интернет-магазин, где все автоматизировано и нет других служб, кроме ИТ. За год моя идея была услышана, но периодически на совещаниях можно услышать: "Это нужно бизнес-направлению!". При этом под бизнесом подразумеваются и другие вспомогательные отделы – бухгалтерия, логистика и др.
Существует и обратная ситуация, при которой в части компаний ИТ-отдел является элитным подразделением, а остальные департаменты находятся в зависимой от него позиции. Это тоже неправильно.
Особенности коммуникаций с ИТ-подразделением
Еще одно имеющееся разногласие, которое я его осознал, когда работал в отделе маркетинга, – разница в системах координат. Приведу пример: дизайнеру пришла задача изобразить "легкий эффект красного ветра с привкусом морской соли, развевающего наш логотип".
Попробуйте это хотя бы представить, я не говорю изобразить. При этом, с одной стороны, у нас заказчик, мыслящий образами, с другой – дизайнер, человек творческой профессии, тоже мыслящий образами. В ИТ ситуация сложнее. ИТ-специалист мыслит в цифровом формате "0/1", "включено/выключено", "да/нет". Соответственно, для того чтобы задумку заказчика перевести в формат кода, нужно несколько итераций. И когда заказчик удивляется: "Зачем вы меня об этом спрашиваете, я же все указал в задаче", это говорит о том, что где-то в цепочке коммуникаций идет сбой по перекодировке.
Как правило, между заказчиком и разработчиком стоит бизнес-аналитик. именно он выполняет функцию перекодировки. Сначала он узнает, что хочет заказчик (функциональные требования). Далее аналитик перекладывает желания заказчика на язык разработчика, формулируя технические требования или то, какие изменения и дополнения нужно внести разработчику в информационную систему. Иногда в цепочке может быть несколько разных аналитиков, которые "перекодируют" документ.
Другой разрыв в коммуникациях – то, что, помимо линейного, необходимо реализовать все возможные сценарии. Простой сценарий пользователя переходит в разработку всех возможных вариантов на стороне ИТ.
Как решать данную ситуацию: прописываем основной сценарий, а также возможные отклонения от сценария (как ведет система во всех остальных случаях, которые не описаны). При постановке задачи желательно предугадать, сколько возможно сценариев ее реализации, всегда следует формулировать: "Если есть отклонение, то…"
Как выстроить взаимодействие со стороны ИТ-отдела
В сегменте ИТ необходимо разделение сотрудников на тех, кто взаимодействует с пользователями, и тех, кто для пользователей недоступен. Для чего это нужно? Дело в том, что в отрасль часто идут интроверты, которым некомфортно общаться. Эти люди предпочитают получить техническое задание и качественно его выполнить. Обычно это высококлассные специалисты разработки, при этом постоянное общение их выбивает из колеи.
Рекомендуется разделить всех сотрудников ИТ-отдела на три группы:
- Сотрудники, которые хорошо взаимодействуют с коллегами. Их направляем на задачи технической поддержки или на решение задач, которые требуют постоянного взаимодействия с пользователями.
- Сотрудники-интроверты. Они выполняют задачи, связанные с разработкой. Работа с данной группой происходит через аналитиков или руководителей.
- Сотрудники, которые могут взаимодействовать, но в ограниченных рамках. С их помощью мы формируем передающее звено, состоящее из аналитиков и тестировщиков, постоянно взаимодействующих с пользователями. Разработчики третей группы общаются только с аналитиками и не общаются с заказчиком напрямую.
Все советы сформулированы исходя из моей практики. Следуя им, вы сможете улучшить взаимодействие между подразделениями, а в некоторых случаях и сохранить команду ценных ИТ-специалистов.
Опубликовано в журнале "Системы безопасности" № 5/2023
Все статьи журнала "Системы безопасности"
доступны для скачивания в iMag >>
Фото: ru.freepik.com
