Журнал "Системы Безопасности" № 5‘2023

S E C U R I T Y A N D I T M A N A G E M E N T 117 реализации. Побочным эффектом может стать ситуация, когда заказчик, проанализировав объем изменений и инвестиционных затрат, может отказаться от реализации своей задачи. Приведу пример изучения задачи перед ее реа- лизацией. заказчик захотел внести изменения в процесс. По результатам изучения задачи выяснилось, что придется вносить правки в про- цессы поставщиков компании, то есть наши разработчики должны были бы исправить информационную систему и цепочку движения товара у поставщика. Помимо этого, поставщи- ку необходимо было закупить определенное оборудование для реализации задуманного. все это позволяло немного улучшить контроль за процессом, однако экономический эффект от таких изменений никогда не был бы достигнут. в результате полученной информации заказчик предпочел отказаться от задачи. Определите ресурсы для реализации задачи Под ресурсами здесь подразумеваются: l бюджет; l свободное время сотрудников; l необходимые компетенции; l наличие подрядчиков и их готовность к работе; l наличие необходимого оборудования. Если не учесть какой-то из перечисленных фак- торов, то количество задач в стадии ожидания реализации будет нарастать как снежный ком. я знаю, что у некоторых компаний данный период составляет год. Даже если заказчики перестанут давать новые задачи, то иТ-подразделение будет работать целый год, чтобы реализовать те, которые им уже были поручены. Что делать в таком случае? я бы рекомендовал проанализировать все текущие задачи и решить, нужно ли их исполнять. Критерии могут быть разными, а вариантов ответов обычно три: "да, нужно", "нет, не нужно", некий промежуточ- ный вариант – "нужно, но сейчас не горит", "когда-нибудь позже" и т.п. Приоритетные зада- чи оставляем и разбиваем по срочности реали- зации. задачи, актуальность которых не под- тверждена, сразу убираем. задачи неопреде- ленной категорией срочности рекомендую заархивировать и забыть. Ситуация быстро меняется, поэтому если вам это не нужно сей- час, то не факт, что понадобится в будущем, – лучше, чтобы наличие таких задач не давило на команду. итак, мы собрали все задачи, распределили по важности и срочности, определились с коман- дой, которая будет их решать, и получился гра- фик выполнения работ по срокам. затем мы информируем всех заинтересованных о графике решения задач, объяснив очеред- ность. Пользователи при обращении получают информацию о плане, а также о том, когда их задача будет взята в работу. При необходимо- сти мы объясняем, почему их задача не высше- го приоритета. Как правило, после грамотного объяснения сотрудники понимают, почему важ- ная для них задача будет решена только в сле- дующем квартале. По итогам такого подхода к работе все сто- роны проинформированы и спокойны. на разработчиков не давит груз нерешенных задач, заказчики не нервничают, так как знают, когда их задача будет реализована. Главное – постоянно отслеживать соблюде- ние ранее намеченного графика при выпол- нении задачи. Не нужно брать больше задач, чем вы можете обработать на горизонте Точный срок горизонта назвать сложно, он у всех разный. Однако подразделения должны понимать, что "в настоящий момент все опера- торы заняты, ваш звонок 50-й в очереди". Руко- водству иТ-подразделения или компании в таком случае следует принять решение о том, как исправить ситуацию. Когда наша компания активно расширяла штат и мы проводили много собеседований, практи- чески все разработчики основной причиной поиска новой работы называли загруженность: задач у сотрудника больше, чем он может про- работать за несколько месяцев, при этом долг, а вместе с ним и давление на сотрудника только растут. на мой вопрос о том, пробовали ли решить проблему наймом дополнительных сотрудников, соискатели отвечали, что нет. Получается, в компаниях на ровном месте соз- давались проблемы, которые приводили к отто- ку кадров. ИТ-отдел должен иметь статус в компании Если в компании принято, что иТ-отдел – это обслуживающий блок, который должен просто выполнять поручения, то в текущих реалиях полноценного взаимодействия не получится. мне стоило больших трудов переубедить раз- работчиков и аналитиков в том, что есть биз- нес-направление и есть иТ-отдел. я придержи- ваюсь подхода, при котором иТ – это часть биз- неса, без которого не может работать ни одно подразделение. мало того, иТ-отдел может самостоятельно исполнять определенный функ- ционал бизнеса, например вести сайт компа- нии, отвечать за кассы самообслуживания и интернет-магазин, где все автоматизировано и нет других служб, кроме иТ. за год моя идея была услышана, но периодически на совеща- ниях можно услышать: "Это нужно бизнес- направлению!" При этом под бизнесом подра- зумеваются и другие вспомогательные отделы – бухгалтерия, логистика и др. Существует и обратная ситуация, при которой в части компаний иТ-отдел является элитным подразделением, а остальные департаменты находятся в зависимой от него позиции. Это тоже неправильно. Особенности коммуникаций с ИТ-подразделением Еще одно имеющееся разногласие, которое я его осознал, когда работал в отделе маркетин- га, – разница в системах координат. Приведу пример: дизайнеру пришла задача изобразить "легкий эффект красного ветра с привкусом морской соли, развевающего наш логотип". Попробуйте это хотя бы представить, я не гово- рю изобразить. При этом, с одной стороны, у нас заказчик, мыслящий образами, с другой – дизайнер, человек творческой профессии, тоже мыслящий образами. в иТ ситуация сложнее. иТ-специалист мыслит в цифровом формате "0/1", "включено/выключе- но", "да/нет". Соответственно, для того чтобы задумку заказчика перевести в формат кода, нужно несколько итераций. и когда заказчик удивляется: "зачем вы меня об этом спрашивае- те, я же все указал в задаче", это говорит о том, что где-то в цепочке коммуникаций идет сбой по перекодировке. Как правило, между заказчиком и разработчи- ком стоит бизнес-аналитик. именно он выпол- няет функцию перекодировки. Сначала он узна- ет, что хочет заказчик (функциональные требо- вания). Далее аналитик перекладывает желания заказчика на язык разработчика, формулируя технические требования или то, какие измене- ния и дополнения нужно внести разработчику в информационную систему. иногда в цепочке может быть несколько разных аналитиков, которые "перекодируют" документ. Другой разрыв в коммуникациях – то, что, помимо линейного, необходимо реализовать все возможные сценарии. Простой сценарий пользователя переходит в разработку всех воз- можных вариантов на стороне иТ. Как решать данную ситуацию: прописываем основной сценарий, а также возможные откло- нения от сценария (как ведет система во всех остальных случаях, которые не описаны). При постановке задачи желательно предугадать, сколько возможно сценариев ее реализации, всегда следует формулировать: "Если есть отклонение, то…" Как выстроить взаимодействие со стороны ИТ-отдела в сегменте иТ необходимо разделение сотруд- ников на тех, кто взаимодействует с пользова- телями, и тех, кто для пользователей недосту- пен. Для чего это нужно? Дело в том, что в отрасль часто идут интроверты, которым некомфортно общаться. Эти люди предпочи- тают получить техническое задание и качествен- но его выполнить. Обычно это высококлассные специалисты разработки, при этом постоянное общение их выбивает из колеи. Рекомендуется разделить всех сотрудников иТ- отдела на три группы: 1. Сотрудники, которые хорошо взаимодей- ствуют с коллегами. их направляем на задачи технической поддержки или на решение задач, которые требуют постоянного взаимодействия с пользователями. 2. Сотрудники-интроверты. Они выполняют задачи, связанные с разработкой. Работа с дан- ной группой происходит через аналитиков или руководителей. 3. Сотрудники, которые могут взаимодейство- вать, но в ограниченных рамках. С их помо- щью мы формируем передающее звено, состоящее из аналитиков и тестировщиков, постоянно взаимодействующих с пользовате- лями. Разработчики третей группы общаются только с аналитиками и не общаются с заказ- чиком напрямую. все советы сформулированы исходя из моей практики. Следуя им, вы сможете улучшить взаимодействие между подразде- лениями, а в некоторых случаях и сохранить команду ценных иТ-специалистов. n www.secuteck.ru октябрь – ноябрь 2023 СПЕЦПРОЕКТ БЕзОПаСнОСТь и ЦифРОвая ТРанСфОРмаЦия РиТЕйла Ваше мнение и вопросы по статье направляйте на ss @groteck.ru