Софт, как трактор

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

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

Для начала необходимо избавиться от иллюзий. В мире не существует идеального программного обеспечения, которое полностью закроет потребности бизнеса и сделает всех счастливыми. Ни одна, самая дорогая система, не работает без ошибок и не обладает набором функциональности, который закроет все хотелки даже не самых притязательных сотрудников, если у них есть хоть какие-то зачатки интеллекта. Когда вам говорят: поставьте наше решение и у вас все будет прекрасно - просто повыясняйте: а какова глубина беклога (очереди) доработок. И стоит поузнавать: а сколько разработчиков трудится в департаментах ИТ лидеров рынка, использующих данное ПО. И, стоит задуматься, почему производители программного обеспечения постоянно присылают какие-то обновления.

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

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

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

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

Руководителям стоит задуматься: давая кому-то команду пособирать хотелки вы не более чем затеваете небольшой CustDev - исследование клиентов, которое должно помочь создать или улучшить продукт. А хотите ли вы заниматься созданием продукта? Ваш ли это бизнес? Качественный CustDev - это дорогая вещь, которую должны делать профессионалы. У вас в команде есть такой профессионал? А те с кем он будет исследование? Они статистически значимы и на них можно опираться? То, что уже заложено в продукты появилось там не просто так. Возможно оно не идеально, но оно рабочее. Если вы не уверены, что у вас в команде есть суперпрофи нужно проявлять мегаосторожность.

Я видел ТЗ от одной огромной торговой сети, которая затеяла смену одного из решений. В труде под сотню страниц содержалось в основном описание того как есть сейчас. Фактически “хотим такое же, но с перламутровыми пуговицами”. Только “такого же” на рынке просто быть не может: “у вас все по спецзаказу”. В других случаях документы содержали кучу фантазий, реализация которых потребовала бы огромного количества ресурсов с интуитивно понятной нулевой эффективностью. Одни витают в облаках, другие привязаны к своей земле. И тот и другой вариант при выборе новой системы не являются лучшими.

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