×Закрыть

Поддержка и развитие продукта в ритейле — за и против

О чём?

Сначала о продукте. Потом о реалиях. Потом о том, как с этим всем работать и надо ли.

Предположим, что в один прекрасный день вы решили поработать в ИТ-отделе какой-нибудь из компаний по продаже неважно чего. У этой компании есть интернет-магазин и колл-центр, офис, сеть классически розничных магазинов, склад, 100500 клиентских тазиков, логистика и какая-нибудь ERP-система (SAP, AX, 1C — нужное подставить самостоятельно или размешать).

Основной вашей мотивацией будет:

  1. Поработать с живыми (ну или полуживыми) бизнес-процессами.
  2. Поработать с настоящими данными на больших объёмах.
  3. Поработать с хорошими нагрузками (т.е. пиковыми).

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

Основными вашими задачами будет:

● Поддержка и развитие бизнес-процессов.

Если тут вы подумали, что должны существовать функциональные обязанности, то глубоко ошибаетесь. Описание должности? Оно чисто для публикации вакансии существует. Написано, что у ИТ такие функции — значит, так и должно быть.

Так с каким продуктом работать?

Вот вам наши остатки ERP (SAP, AX, 1C). И сайт наш — это же интернет-магазин! Да, он давно существует. Да, было дорого, и мы отказались от **** в пользу bitrix. Идиоты, говорите? Конечно, столько платить в месяц, до сих пор не поймём, за что. Остатки когда обновляем? Так вместе с ценами, раз в сутки. Магазины вот с утра всё получают, и интернет-магазин тоже. Что вам делать? Так вот сядьте, с подрядчиком задачи сведите, там вроде не всё закончили они. И там за стенкой серверная — проверьте, всё ли там на местах, а то недавно стенку разбирали, что-то сеть пропадала.

Распределённый контроль версий? Ну, в 1С вот есть хранилище, есть версии — вы об этом? Каких разработчиков нужно найти, что ещё за web-разработка?

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

С чего начать?

  1. Минимизировать хаос. Поднять / арендовать трекер.
  2. Минимизировать почту (и неважно, что так общается вся компания — есть трекер).
  3. Понять, кто где и чем занимается.
  4. Закрыть незакрытое годами (договора с подрядчиками итп).
  5. Понять, где и зачем нужны подрядчики.
  6. Пробить позиции, найти и нанять людей (всё может происходить в разной очерёдности).
  7. Определить цели, задачи, показатели.
  8. Определить, как работать.
  9. Начать работать.
  10. Начать общаться с внутренними и внешними заказчиками. Притом голосом. Притом регулярно.
  11. Начать работать с подрядчиками.
  12. Начать тестировать (наконец), не только пользователями.
  13. Пробить ещё пару серверов для dev / stage / production.
  14. Повторить пункты 5-13 при увеличении кол-ва задач, при необходимости.

Как будет выглядеть рабочий день:

  1. Посмотреть трекер.
  2. Почитать почту.
  3. Посмотреть трекер.
  4. Почитать почту.
  5. Завести одну-две-три таски.
  6. Сходить на совещание раз.*
  7. Встретиться с каким-то подрядчиком.*
  8. Посмотреть почту.
  9. Сходить на совещание два.*
  10. Посмотреть почту.
  11. Сходить на совещание три.*
  12. Встретиться с каким-то подрядчиком.*
  13. Посмотреть почту.
  14. Нормально поработать после 18:00, поговорить с командой, определить список на заливку, узкие места и планы по работе команды на завтра / неделю.

Отмеченное * - опционально, количество каждого вида может варьировать от одного до восьми, в разных пропорциях, но никогда не больше восьми.

К чему нужно быть готовым:

  1. К тому, что никому ваши начинания не нужны. Ни отточенный внутренний рабочий процесс, ни таски в менеджере, ни навыки по искусной их оценке и прогнозированию, ни развитая команда, и тем более любой из подходов к разработке.
  2. К десяткам менеджеров по продажам, которые в почту и по телефону будут навязывать очередной мониторинг цен / конкурентов / разработку ещё одного приложения etc.
  3. К тому, что ваши условия будут всегда отличаться от рыночных. Причём в разные стороны.
  4. К тому, что от вас ждут не результат. А просто дату релиза (неважно чего).
  5. К тому, что никто (почти никто) не знает про ITIL и ITSM.
  6. К тому, что всё зависит от вас, вашей команды и вашего непосредственного руководства.
  7. К тому, что главнее CEO бывает бухгалтер. И это никак не связано с начислением ЗП.
  8. К тому, что нужно рисковать. Иногда очень часто.

И всё же, если вы решили идти и работать с продуктом — то вам следует на год-второй окунуться в дебри отечественных компаний. Страшного в этом ничего нет — проверено :)

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Добрый десяток раз через это проходил. Алгоритм куда проще:
1) Оно работает?
ЕСЛИ худо-бедно да => достать х&й и привычную дозу кофеина. Попытаться раздобыть документацию. Попытаться раздобыть того, кто знает больше всех.
ЕСЛИ нет => попытаться узнать когда всё началось. Только правду. Начальство любого уровня спрашивать бесполезно, их придётся убить раздавив череп вручную — до тех пор они не перестанут пиzдеть. Любое начальство в случае проблем всегда пиzдит как последние суки. Такова традиция постсоветской зоны, кстати она закладывается ещё с детсада и школы.
Лучше всего добыть мыло саппорта. Лучше пользователя проблему никто не опишет. По крайней мере описание пользователем поможет отличить правду от версий.

2) Главнее всех клиент. Если клиент уходит, мне не похер. Если вам похер — то мне похер ваша компания, я с м-дакми не работаю принципиально. До тех пор пока я с вами работаю, клиент не уходит.
2а) Если СЕО думает что он главнее клиента — я открытым текстом озвучу то, что говорят пользователи. И поставлю перед фактом, что если клиент уйдёт — то я буду первый кандидат на неоплату, потому что пришёл в компанию последним. Потому если хочет уволить — звонок в любое время, с оплатой сделанного.
2б) В случае неоплаты — убиваю репутацию компании. Без вариантов. Уговор дороже денег. Исключение — если сохранение репутации было частью уговора (но это очень специфические клиенты).

3) Живой бизнес стоит на 1-2 порядка дороже мёртвого. Мне плевать на чём он работает, хоть на девчёнках, которые набирают заказы на клавиатуре и выписывают накладные от руки. Воскрешение бизнеса — задача не под силу даже джедаям. Иногда есть вариант приостановки или сезонной гибернации, но никак не смерть.
3а) Проект может быть мёртв организационно. Это не значит что бизнесу каюк, лишь тот факт что отмирающие части нечем заменить, а незаменимых звеньев цепи уже есть. Процесс обратим на любом этапе, даже при угрозе банкротства. Убивать невыгодно — живым он стоит денег даже не имея денег.

0) Бизнес-логика может писаться на всём, что готов исполнить компьютер. Появление новых фреймворков, сервисов, моды — ПРАКТИЧЕСКИ НИЧЕГО НЕ РЕШАЕТ. Это не ITшная категория вообще. Я знаю бизнес, у которого 3 года назад сервера крутились... на Windows 98. И это успешный бизнес, в США.
Бизнес-логика может работать вообще без компьютеров. Может. О конкурентоспособности вопрос отдельный, но даже если в стране восходящего тризуба вырубят свободный интернет — весь бизнес не накроется.

Что на самом деле имеет значение:
1) Формализация процессов. Если всё идёт по понятным простым правилам — неразрешимых проблем нет. Есть предсказуемые затраты на обновление, и управляемые риски процесса.
2) Отсутствие ручного регулирования как «нормального» процесса мотивации-демотивации.
Если в компании всё построено на власти, если есть необходимость постоянно доказывать полномочия по принципу «я начальник — ты дурак» — компания организационно мертва.

Если компания имеет организационные проблемы, с которыми неспособна справиться — ВНЕДРЕНИЯ IT ПРОТИВОПОКАЗАНЫ. Это катализатор, который только ускорит распад и позволит просрать средства.
Всё остальное настолько мелочи по сравнению с дебильной организацией, что практически любой современный процесс можно отдать на аутсорс. Кроме построения живой внутренней системы. А там хоть на почтовых голубях пусть общаются, хоть на черепахах ездят и на матричных принтерах печатают (как Укрпочта).

0. Да *лять, мне больше всех надо.

Подписаться на комментарии