Мы разрабатываем open-source базу данных для не-программистов. Вот про нее статья на VC или вот репозиторий на GitHub.
Это статья из учебных материалов для партнеров и пользователей, разрабатывающих систему для себя самостоятельно. Так-как вопрос «На что смотреть, чтоб успешно запустить внутреннюю учетную систему?» в большинстве случаев даже более важный чем технические заморочки по проекту.
Итак поехали:
Люди понимают друг друга с трудом — это факт! В сфере IT это непонимание можно смело умножать на 10: заказчик мечтал об одном, внедрили вроде то, но другое… В итоге все удивлены, хотя хотели как лучше. Какие системные баги характерны в общении разработчика и заказчика, и как их отловить в самом начале, пока они не привели к краху проекта?
Если вы разработчик
Еще до того, как приступить к разработке какой-либо внутренней учетной системы, важно точно определить, кто будет контактировать по всем вопросам разработки со стороны компании: с кем разработчик будет общаться, обсуждать ТЗ, тестировать ПО и т. д. Уже на этом этапе могут быть интересные сюрпризы. Если вы и заказчик и разработчик в одном лице — оцените свое свободное время на задачу разработки — его всегда требуется больше, чем ожидаешь.
Кому это надо?
Если разрабатываемая система не перераспределяет роли внутри компании, есть вероятность, что она вообще бессмысленна. В норме она должна автоматизировать процессы, в результате чего будет меняться баланс денег, полномочий и объема работы.
Такие перемены кому-то внутри компании могут быть выгодны, а кому-то абсолютно нет. Например, владельцу компании нужна система финансового учета. Но он не хочет разбираться, как именно ее построить, поэтому спускает задачу финансовому директору. А финдир думает: за что я буду получать свою прекрасную зарплату, если значительный процент моей работы автоматизируется?
Другой вариант: начальник производства создает иллюзию завала при условии, что у него там работы — на три часа в день. Он так делал годами, а тут на него напускают программистов, которые сейчас раскроют всю аферу.
Не всегда, конечно, все так критично. Но описанные случаи — из нашей реальной практики. В этих двух случаях, в частности, нам приходилось работать с заказчиком, который всеми силами саботировал разработку и внедрение ПО. А после всех наших усилий пытался доказать руководству, что система не работает. И в одном случае мы ничего не смогли доказать и оказались крайними.
Итого, чтобы избежать саботажа и других осложнений, важно выявить истинного интересанта, а также проанализировать, как проект нарушает текущие интересы сотрудников компании — и кто из них может оказать негативное влияние на разработку. Основным контактом со стороны компании должен стать человек с достаточным количеством полномочий и личной заинтересованностью в успехе внедрения.
Чур не я!
Если вы нашли лично заинтересованного человека с полномочиями, далеко не факт, что он захочет с вами работать. Например, в небольших компаниях заказчик, как правило, первое лицо компании — владелец или директор. И чаще всего он пытается самоустраниться из общения: мол, я вам деньгу плачу — давайте сами придумайте, что надо.
Причин такого поведения может быть много. Одна из них:
«Коллеги, я хороший и за вас, а новые правила — от злых айтишников, ничего поделать не могу».
И неважно, что ему самому надоело, что болты со склада воруют. Он сохраняет имидж и отношения, а болты возвращаются на склад чужими руками.
Другой вариант: «Я серьезными делами занимаюсь, мне некогда вникать в детали». Или: «Вы специалисты, вам виднее — сделайте как надо». Если со стороны заказчика минимум интереса, информации и содействия, то даже часть реализованного функционала можно считать большой победой.
В крупных компаниях, кстати, тоже возможен такой вариант: народу много, но все хотят отползти — «чур не я». Обратный вариант еще хуже: все пробивают себе контрольные функции, чтобы получить максимум результата на своем участке. Во таком случае, если разработчик идет на поводу у всех, система рискует стать избыточно сложной и погибнуть под собственным весом. Она будет настолько сложна и неудобна для пользователя, что в результате никто не станет с ней взаимодействовать.
Надо выявить одну из этих двух стратегий как можно раньше, по возможности провести воспитательную работу, спланировать адекватные результаты — вопреки желаниям или неделаниям всех участников.
Если вы заказчик
В умах многих заказчиков жива идея о том, что разработка внутреннего корпоративного ПО не имеет к ним отношения: дал задание — и ждешь, когда все случится. Давайте разберем, как все выглядит на самом деле.
Будте внимательны если:
Сейчас все напишем — только дайте денег! Если вы слышите от разработчика идею о том, что сейчас без вашего участия все будет сделано на 500%, будьте уверены, с вас просто хотят взять денег. Ничего хорошего из такого подхода еще ни разу не получалось: в лучшем случае — пара полезных функций из 20 запланированных, в худшем — просто мертвая система, в которой никто никогда работать не сможет.
В расчет стоимости ПО надо закладывать затраты со стороны компании — время и трудозатраты людей, которые будут взаимодействовать с разработчиками, плюс обучающий процесс при внедрении, плюс еще множество факторов, которые заранее не просчитать. Стоить это будет в среднем столько же, сколько и сама разработка — и эти расходы надо заложить в бюджет.
Эффект ПО в деньгах оценить нельзя — это же удобство/имидж компании PR, требование времени. Если вам говорят такие фразы, бегите! Профит должен быть очевиден, и именно в деньгах. Поверьте, вам, как заказчику, предстоит приложить столько усилий к внедрению нового ПО, что ради пиара даже думать об этом не стоит.
Профит от внедрения новой системы должен за пять лет пятикратно превысить затраты на разработку. То есть система в норме должна окупиться за год. Причем, при расчете бюджет на разработку умножаем на два — потому что с вашей стороны, как мы помним, будут затраты, в среднем равные стоимости ПО.
Плюс после внедрения и обучения надо запланировать оплату обслуживания системы, так что пятикратная потенциальная выгода — это минимальный порог. Чем выше ожидаемый профит от внедрения, тем больше шансов на успех.
Что делать чтобы сориентироваться?
Я рекомендую следующий список вопросов, который позволяет прояснить, какая выгода возможна благодаря внедрению ПО:
- Три существующие на сегодняшний день проблемы, которые должно решить новое ПО
- Какой прогнозируется денежный эффект в течении 2-х лет от запуска системы в работу?
- Каким образом осуществляется решение проблемных задач сейчас?
- Почему текущее решение перестало быть работоспособным? Что изменилось в вашем бизнесе/ секторе рынка за последний год, что привело к невозможности использовать текущие методы дальше
Ответьте на эти вопросы 👆, и необходимость разработки значительно прояснится.
Особенно актуален вопрос «что изменилось в последнее время»: он взят из методологии Lean Startup. На него нужен четкий ответ. Если ничего особо не изменилось, то мотивация в преодолении трудностей автоматизации очень и очень сомнительна.
Техзадание для разработчика и заказчика
Итак, заказчик решился сотрудничать с разработчиками, чтобы построить систему мечты (которая объективно необходима). Разработчики оценили интересантов и нашли себе союзников со стороны компании. Пришло время составить техзадание.
Какие засады ждут на этом пути?
Хочется составить такое техзадание, которое сразу отразит все интересы компании, покроет ее нужды и на пальцах объяснит всем участникам событий, что будет происходить.
Так вот — это невозможно!
Когда вы проектируете систему на листочке — это система на листочке.
Если его отдать разработчику и подождать несколько месяцев, пока он ее сотворит — вы получите очень неожиданный результат. Многие веще окажутся неудобными, что-то будет лишним, чего-то не будет хватать. Причем, не хватать будет самого важного, зато самое ненужное будет лезть со всех сторон. Чем масштабнее запланированная система, тем больше будет разрыв между реальностью и листочком.
Что делать?
Не пытайтесь сделать одно большое качественное техзадание. Хорошим подходом можно назвать следующую последовательность:
выделить из всей планируемой работы центральную стартовую часть
согласовать ее блок-схему и основную логику
разработчик — начинает реализовывать эту часть
заказчик — оперативно предоставляет обратную связь по мере готовности каждого блока
Обратите внимание, обратная связь нужна оперативно: то есть с момента, когда заказчику прислали какую-то часть на тестирование, до ответа должно пройти не больше 2-3-х дней. Как только заказчик начинает откладывать, забывать, забивать, игнорировать тестирование, программисты теряют обороты в разработке и, в конце концов, могут переключиться на другую задачу. Тогда предыдущая просто ляжет мертвым грузом где-то в переписке.
Главная задача обоих сторон — как можно быстрее «оживить», то есть начать использовать систему. В процессе рождения живого существа важны сроки, в которые оно появится на свет: слишком длительные роды — угроза гипоксии и смерти. Создание ПО — такой же живой процесс: если система не входит в употребление немедленно после создания, она имеет риск превратиться в зомби-систему. То есть она будет существовать чисто номинально, но все потоки данных будут проходить по другим каналам.
О зомби-системах мы поговорим в следующей статье. Это такие программные монстры, в которые вкладываются деньги и силы — и которыми потом никто никогда не пользуется. Они могут возникнуть по причинам, описанным в этой статье (например, при успешном саботаже со стороны анти-интересантов), а могут — по ряду других неожиданных причин.
P. S. Мы там PRO бесплатно раздаем за звездочки на GitHub.