Этап первый: создание продукта лично для себя, сделаем все лучше, круче и волшебнее

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

Вследствие этого ИТ-подразделения или целые ИТ-компании зачастую стартуют внутренние проекты по созданию того или иного продукта, несмотря на уже имеющиеся на рынке аналоги. Одним из примеров подобных проектов является разработка традиционного таск-менеджера. Ведь подавляющее большинство компаний с проектным управлением (а таковыми являются все ИТ-разработчики) используют в своей работе решения для контроля и управления задачами. Мысль о создании собственного, максимально заточенного под нужды компании сервиса возникает в головах большого числа программистов, особенно после многократных и не всегда успешных попыток «допилить» западные решения под свои, не всегда стандартные потребности.

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

Этап второй: приходит понимание, что всё не так просто, но надежда создать идеал греет душу

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

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

В таких условиях создать из прототипа MVP не слишком-то простая задача. Долгий путь от идеи до ее реализации иногда становится непреодолимой преградой при создании любого ПО. А разработка для внутренних нужд компании часто усугубляется большим числом доработок прямо в процессе, под лозунгом «для себя же делаем, а давайте еще вот так попробуем». Итого зачастую ИТ-подразделениям приходится проворачивать огромный объем рутинной работы, периодически идущей «в корзину» чтобы довести систему до состояния, когда ее можно начать использовать.

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

Как же обстоят дела в случае разработки сервиса для управления задачами и проектами?

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

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

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

И о чудо! Многократно поменяв, переделав и переместив всё, что было можно и нельзя, удивительным образом получается тот самый, отражающий персональные «хотелки» и пожелания продукт. Остается лишь внедрить и начать работу.

Этап третий: а вдруг то, что сделали лично для себя, нужно еще кому-нибудь?

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

Конечно, помимо стандартных функций клиенты зачастую начинают просить и что-то особенное, необходимое лично им. В случае с таск-менеджерами, например, важным условием в запросах клиентов упоминается возможность установки продукта on-premise, т. е. развертывание на собственной инфраструктуре компании. Такой подход ожидаем в текущих реалиях, ведь в отличие от облачных решений, в подобном варианте заказчик осуществляет полный контроль над серверами и сетью, а значит над системой и данными в ней.

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

Этап четвертый: куда дальше и что же там за горизонтом?

Что же на сегодня происходит в сегменте упомянутых выше таск-трекеров? После ухода из РФ Atlassian (создателя Jira и Trello), отечественные сервисы для управления задачами и проектами появляются как грибы после дождя. Кажется, только ленивый не написал собственное решение из этого ряда. Но что наиболее востребовано сейчас и на что в первую очередь обращают внимание заказчики?

В ряду необходимого функционала все чаще требуются следующие позиции:

  • Возможность работы с отечественными ОС (Astra Linux и др.).
  • Установка продукта on-premise.
  • Интеграция со смежными решениями — репозитории кода и артефактов, базы знаний (аналоги Confluence), средства автоматизации процесса производства и тестирования ПО и пр.
  • Возможность адаптации решения под требования КИИ и кастомизация сервиса для отраслей, которым использование отечественных решений особенно актуально в связи с высокими требованиями к безопасности.
  • Разработка мобильного клиента (в том числе под ОС Аврора).

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

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

Резюмируя все вышесказанное, хочется со всей ответственностью заявить — несмотря на ожидаемые и совершенно неожиданные сложности, идея создания своего продукта и дальнейшего вывода его на рынок вполне реализуема в жизни.

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

Так что, сил и терпения нам всем и да пребудет с нами сила волшебных слов «стоп, правки больше не принимаются».

Александр Чемоданов, технический директор компании IconSoft