ИТ-Стайер

А за дверью триста мужиков, которые простаивают, а это хуже чем триста спартанцев. У тех хоть все понятно, а у этих горит заработок.

Поиски ничего не дают, все штатно. Ситуация накаляется.

В какой-то мере повезло, потому что в это же время в Кропоткине был руководитель РЦ из Энгельса. Поинтересовавшись в чем проблема и глянув на “новый” отборочный лист он сказал, что уже месяц по такому работает. На вопрос “как так? и как справился с проблемой?” он сказал, что ему админы передали, что вот такую новость прислали из Краснодара и теперь будет так. Он собрал народ, благо у него склад поменьше и народу тоже, проинструктировал по новому и все прошло гладко.

Оказалось, что “новый отборочный лист” был включен в тест, который проходил на РЦ Энгельс и поскольку никаких отзывов не последовало, то сопровождение посчитало, что все прошло отлично и включило его в плановую установку, которую робот и выполнил, когда смог. Когда причину нашли, то проблему устранили в несколько минут.

Надо сказать, что пока выясняли, скандал поднялся до самого верха и принял вид бросания телефонов и крепких выражений. Такое периодически случалось, но когда заслужили, тогда заслужили.

Минут через пятнадцать на вопрос “как обстановка?” руководитель отдела сопровождения отстучался в аську: “Все нормально. Заходил СН. С …. перешел на имена”.

И уж если вспомнился Сергей Николаевич Галицкий, то в контексте разговора о “владельцах продукта”, мне думается, успех Магнита связан именно с тем, что его собственник и руководитель отлично соответствовал этой роли применительно к торговой сети.

Глава 10

Как бороться с хроническим недостатком ресурсов

Самая распространенная претензия к ИТ-шникам это то, что они никогда не успевают. Всегда есть куча пожеланий от бизнеса, которые нужно было сделать еще вчера. Очередь заявок на доработки исчисляется десятками и сотнями. Любой менеджер при разговоре с руководителем обязательно сошлется, что ждет чего-нибудь от разработчиков и по этому что-то не успевает или не может сделать.

Такая ситуация вполне объяснима. Современный менеджмент – это в основном решение информационных задач. Для их решения постоянно требуются какие-то данные, которые нужно либо получить, либо изменить.

Людям приходит в голову масса идей. Каждая идея сразу кажется стоящей и требует своей просто немедленной реализации. При этом нормальная лень сразу ищет возможности переложить рутину на кого-нибудь и самые первые кто тут приходит на ум – это ИТ-шники. Пишем заявку и ждем пока нам ее не сделают. При этом у нас есть успокоительное для себя и отмазка для начальства.

Так и возникает дефицит ресурса. В большинстве случаев все упирается в программистов, которые заняты всегда. Мы уже говорили, что именно отсюда у подразделений возникает желание заиметь своего собственного программиста и я высказывал свое мнение, что идти этим путем ни в коем случае нельзя.

Казалось бы самый простой путь решения такой задачи – это набрать программистов. Если у бизнеса есть потребность и он “готов за это платить”, то почему бы и нет. Ну или не набрать, а привлечь на аутсорсинг. Давайте быстро наберем или привлечем и решим проблему за день-два.

К сожалению, в разработке так не работает. Это сложно воспринимается, поэтому я обычно привожу два примера. Нужно ли два человека, если требуется забить гвоздь? И если бетону для застывания требуется 28 дней, то как повлияет на это наличие 5 или 10 рабочих.

Сфера программирования не относится в тем областям, где в расчетах можно опираться на трудодни или человекомесяцы и линейно сокращать время за счет наращивания людей в команде.

Однажды, работая в Магните, мы решали одну достаточно несложную задачку в интересах транспортников. Вопрос касался регистрации прибытия/убытия автомобилей на торговую точку. Времена были древние, GPS было еще не в моде и мы делали отметки с использованием электронного ключа. Эта система была отработана на супервайзерах магазинов, сотрудниках безопасности, но у транспортников возникла проблема, поскольку в отличии от остальных, водители иногда попадали в интервал, когда система магазина была на обслуживании и база данных была недоступна для записи информации. И вроде бы чего там делать: давайте запишем куда-нибудь, а потом проверим доступность базы и перенесем данные. Только вот специалисты знают, что если делать по уму, то почему-то вылезет куча деталей: записать нужно туда, где просто так не достанешь, где точно никто не подменит; нужно обеспечить, чтобы информация не потерялась и не задублировалась – короче есть тысяча мелочей, с которыми нужно просто повозиться.

Задачу взяли в работу вчера и срок в три недели я обозначил руководителю Департамента транспорта в 3 недели. Расчет прост: неделя на разработку, неделя на тестирование и неделя на гарантированную раскатку обновления по всем торговым точкам. В районе обеда раздался шум в коридоре и ко мне в возбужденном состоянии залетел Галицкий вместе с Директором по транспорту.

– Как три недели? Там же нечего делать!

– А вот так. Разработка, тестирование, раскатка..

– Да я на свободном рынке сейчас найду команду, которая это за 3 дня сделает!

Короче тема закончилась спором на месячную зарплату при круглых глазах присутствовавших, оперативным написанием формализованного упрощенного технического задания (фактически перечня функциональных требований), которые уложились плотненько в полтора листа и тишиной на 3 недели. Кстати, успели мы на пару дней раньше – но это скорее повезло. Наличие ефрейторского запаса в один-два дня – это норма при озвучивании сроков.

Я был уверен, что никакая команда ничего нормального кардинально быстрее сделать не сможет. У нас программированием занимался один человек и потом ему помогали с тестированием и документированием.

Кстати, есть такой эффект, который описан в различной литературе, что оптимальным количеством людей к команде, которые работают над одной задачей пять плюс-минус два. Дальше начинаются проблемы на уровне организации взаимодействия и производительность падает.

Наращивать коллектив имеет смысл тогда, когда вы можете нарезать его на достаточно независимые команды, каждая из которых будет решать свою в какой-то степени изолированную задачу и при этом они не погрязнут в вопросах взаимодействия и интеграции.

Так сколько же программистов нужно держать? Это очень сложный вопрос. В моем понимании, ровно столько сколько вы сможете озадачить и еще немножко. А хороший ИТ-директор, поверьте может озадачить очень много.

Нужно понимать, что пришедший с улицы человек на начальном этапе скорее является обузой для разработки. Он отрывает ресурс самой боевой части коллектива. Сам он будет входить в курс дела непонятно сколько, а наставничество еще тот процесс.

По-моему опыту программисту для адаптации требуется от месяца до полугода.

Кстати, нужно сказать, что работая в Магните, я был, наверное, единственным директором, который регулярно получал за то, что не набираю людей. При этом вакансии у нас висели всегда, но поток кандидатов был просто никакой, или приходили люди, вкладываться в которых по нашему мнению было бессмысленно. Краснодар в те времена точно не был ИТ-шной вотчиной.

Ситуацию сдвинуло, когда мы с Директорам по кадрам пошли в местный университет пообщаться с выпускниками. С первого же захода мы привлекли на стажировку четверых. И как оказалось очень удачно. Все потом вышли на работу и кто-то даже сделал определенную карьеру внутри компании.

Насколько я знаю, Магнит потом расширил практику взаимодействия с университетом. Я тоже потом, работая и в Донецке и Хабаровске, успешно сотрудничал с местными ВУЗами. Мы проводили совместные мероприятия и на мой взгляд это было взаимовыгодно.

Про аутсорсинг мы уже говорили в главе 7. В части наращивания ресурсов программистов, мой опыт говорит, что это далеко не лучший вариант.

Вообще, наращивание ресурсов программистов – это игра в долгую. Этот вопрос относится к разряду стратегических и подходить к нему нужно очень взвешенно.

С точки зрения устранения дефицита программистов есть другие варианты, которые могут дать более существенный эффект.

Очень важным является правильно организовать систему поступления и приоритизации и выполнения заявок.

Крайне позитивным в моей практике стало создание входного фильтра на входе в виде подразделения, которое осуществляло предварительную сортировку и адаптацию заявок.

Оградить программистов от “диких пользователей” – это означает, как минимум, вдвое повысить производительность их работы.

Полезно когда кто-то перед тем как задача попадет непосредственно к программисту:

– рассортирует реальные доработки от инцидентов

– определит имеет ли место реальная ошибка в коде или проблема кроется в каких-то настройках или в данных

– проверит заявку на дублирование с уже имеющимся функционалом, уже существующими заявками и на конфликт интересов с другими подразделениями

– проработает задание с пользователем и переведет его на язык более понятный программистам

– согласует приоритеты выполнения

Это все точно может сделать человек с менее дефицитной квалификацией, чем программист-разработчик.

Тестирование, написание инструкций – это из той же области. Единственное с тестированием нужно не перегибать. Программист обязан первичное тестирование проводить сам, иначе начинается никому не нужный футбол с тестировщиками.

Важным моментом является разделение потока заявок на инциденты и доработки. Безусловно обработка критических инцидентов – это всегда аврал и на нее бросаются лучшие силы, которые бросают все и кидаются в атаку, но такие события при правильной постановке дела должны быть чем-то редким – из ряда вон выходящим. А вот разборка текущих ошибок очень хорошее занятие для обеспечения роста, которое позволяет хорошо изучить систему, посмотреть как принято делать, ну и главное не отрывать имеющуюся гвардию от решения текущих боевых задач.

Если говорить про доработки, то есть тоже одна хитрость, которая поможет сократить их количество. Не секрет, что работа “на корзину” может составлять от 30 до 70% от всего того, что делают программисты. За этим стоят не только потери связанные с оплатой оказавшегося бесполезным труда, но и очень серьезный демотивирующий фактор. Борьба с этим ведется по разному. Кто-то даже вводит штрафы за неиспользуемые отчеты и программные модули, но это ни к чему хорошему не приводит. Потратили бестолково время на программирование и продолжаем тратить время на бестолковое формирование, “чтобы меня не оштрафовали”. Гораздо более действенной является организация возможности попробовать с помощью Экселя. Оказалось, что наличие даже одного кудесника Экселя, который хорошо владеет всеми тонкостями его использования, включая макросы и VBA, позволяет существенно облегчить труд программистов и сделать счастливыми многих пользователей.

Часто ощущение недостатка ресурсов программистов связано именно с реакцией пользователей, которые ходят и бубнят, что мы какую-то мелочь не можем получить уже год. И проблема заключается в том, что это именно мелочь, постоянно непроходящая фильтр приоритетов. Всегда находится, что-то более срочное и важное: ну где там сравнивать подсветку какой-то строчки с глобальной переделкой структуры справочника. Вот так эта строчка и остается неподсвеченной годами и создается впечатление, что программистов не хватает.

Очень полезно периодически устраивать паузу в глобальных работах и посвящать неделю мелким доработкам, которые создадут “п-ш-шь эффект”. Так я называю те изменения, которые по сути ничего глобально не решают, но имеют существенное внешнее проявление. Этот термин достаточно быстро приживался в среде куда его приносили. Подобное мероприятие имеет больше маркетинговую составляющую, чем реальную технологическую, но правильный маркетинг ИТ-подразделений внутри компании очень важен с самых разных точек зрения, начиная от формирования HR-бренда и заканчивая поддержкой имиджа компании в целом, как современной и технологичной.

Со временем ко мне пришло понимание, что маркетинговое сопровождение деятельности ИТ-подразделений играет очень серьезную роль. Оптимизировали вы какую-нибудь процедуру и задача, которая решалась раньше минуты, стала выполняться в пару секунд. Уверяю вас, что большинство пользователей воспримут это как что-то естественное и само собой разумеющееся. То, что над этим 3 человека работали две недели останется за кадром, если конечно вы на этом не акцентируете внимание.