Заметка об обновлении функционала и сроках выхода новых версий

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

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

Причина №1. Разработка ПО – это не бизнес-процесс.

Точнее сказать, разработка НОВОГО программного обеспечения — это не бизнес-процесс. Сама по себе разработка ПО может быть процессом, например, если вы разрабатываете типовые сайты, то вы легко можете оценить трудоёмкость поставленной задачи и рассчитать время выполнения работ. Нам же постоянно приходится сталкиваться с новыми задачами, опыта решений которых у нас нет. Например, мы решили сделать BPM-модуль с исполняемыми процессами, для этого нам следует приобрести и использовать новый компонент, изучать руководство пользователя и техническую документацию на этот компонент. Невозможно заранее предвидеть с какими проблемами технического плана наша команда разработчиков столкнётся при разработке и интеграции данного компонента в нашу программу и сколько времени понадобится на их решение. Вы можете возразить, почему бы не привлечь к этим работам специалистов, имеющих опыт работы с данным компонентом? Дело в том, что, во-первых, в большинстве случаев мы реализуем такие функции, которых в других программах нет, а во-вторых, программ для бизнес-моделирования, разработанных на рынке стран бывшего СНГ, я знаю всего 4, соответственно ни о каких специалистах с таким специфическим опытом разработки не может быть и речи.

Причина №2. Изменение приоритетов.

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

Причина №3. Ошибки во внешних компонентах.

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

Самая главная причина

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

  1. Можно устанавливать прогнозируемый срок и пересматривать его каждый раз, когда возникает непредвиденная ситуация.
  2. Можно устанавливать конечный срок с учётом всех возможных форс-мажоров, грубо говоря, указывать срок в 1 месяц на функции, которые изначально планировалось сделать за неделю.
  3. Можно реализовывать функции в планируемый срок любой ценой, «обрезая» проблемный функционал или оставляя его на потом.

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

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

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

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Вы можете использовать эти HTMLтеги и атрибуты:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>