ИТ-Стайер

Еще одна история связана с распределительными центрами. Мы как раз только начали заниматься разработкой собственной WMS-системы и много времени проводили на складе в Кропоткине.

Меня зовет руководитель РЦ и в панике говорит, что у них поменялась форма отборочного листа, отборщики отбирают неправильно и товар вместо штук неконтролируемо уходит блочками.

Штучной отборки в то время на РЦ было не много, но товар там был дорогой. И если у тебя вместо единицы уходит шесть при цене в 400 рублей – это точно не хорошо, особенно, если учесть, что на снабжении было магазинов под триста.

Начинаем разборки. Вопрос разработчику, который занимался печатью отборочных листов: “Что меняли?”. Сегодня ничего в листах не меняли. Но лист другой. В общем чудеса.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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