ИТ-Стайер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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