Thu 26 Oct 2006
Немного довести напильником…
Posted by Alex Lebedev under процесс разработки, инструменты
[2] Comments
Давным-давно, в одной далекой галактике корпорация “Пупкин-Трейд”, дистрибьютор ароматизированных плющевых медведей в уездном городе Н, захотела внедрить информационную систему. Выбор пал на стандартный продукт “2D Предприятие”. Быстро выяснилось, что используемую у них модель складского учета невозможно представить в системе: отсутствуют необходимые атрибуты и операции, жизненный цикл единиц хранения и близко не похож на реальность, возможные настройки системы не позволяют даже в первом приближении решить проблему. Перед маленькой, но гордой компанией остро встал вопрос “Что делать?”.
Эта проблема настолько распространена, что в ту самую минуту, в которую вы читаете эту статью, в нескольких местах страны грустные люди тихо кроют матом коробочные продукты, не стыкующиеся с таким важным технологиями. С ней сталкивается практически любая организация, желающая автоматизировать (хотя правильнее было бы сказать “информатизировать”) свою деятельность. Технологические процессы каждой организации хотя бы в некоторых аспектах уникальны. В результате, при попытке использования готовых продуктов автоматизации деятельность выясняется, что часть деятельности не может быть адекватно представлена в стандартной информационной модели.
История показала, что есть три основных решения.
Приведение системы поддержки процесса в соответствие с технологией
Тут, опять-таки, есть несколько основных способов:
- Заменить выбранную систему на другую, более функциональную и богатую настройками. Основной риск заключается в том, что новая система, лучше соответствуя технологическому процессу, может быть заметно дороже или (а и иногда и “к тому же”) хуже качеством.
- Написать с нуля свою систему, полностью удовлетворяющую требованиям. Вариант хорош тем, что “отменяет” большую часть ограничений на конечный результат: вы сможете сделать именно то что вам нужно. Основная проблема этого подхода в том, что затраты на разработку и поддержку, вероятно, превысят запланированные в несколько раз. Так практически всегда случается в разработке софта, но за эти-то внутренние поделки вам никто не платит.
- Написать расширение к существующей системе. Альтернатива предыдущего варианта с разменом простоты написания на дополнительные ограничения и зависимость от чужого API.
Приведение технологии в соответствие с поддерживающей системой
Это может быть как хорошим, так и очень плохим вариантом. Все зависит от того, насколько новый процесс будет лучше или хуже старого и от того, чего вам будет стоить переход. Бывает, что в отсутствии информации о классических решениях типичных проблем люди создают очень экзотические технологии, не дающие особых преимуществ по сравнению со стандартными: типичное проявление синдрома изобретения велосипеда в организационном пространстве. В этом случае стоит воспользоваться случаем и заменить доморощенное решение стандартным. С другой стороны, часто бывает, что стандартная технология не годится. Такие случаи надо распознавать заранее, иначе попытка внедрения стандартной технологии приведет к очень болезненным последствиям.
Организация эффективной работы при несоответствии системы и технологии друг другу
На мой взгляд, этому решению уделяют незаслуженно малое внимание. Считается, что несоответствие технологии и поддерживающей системы - это очень плохо. Вполне справедливое мнение, если речь идет о крупных несоответствиях. Но когда мы говорим о мелких несоответствиях, то затраты на устранение могут превышать все неудобства, которые существование проблемы вызовет в ближайшие 99 лет.
Например, Trac, коим мы активно пользуемся, поддерживает только очень базовый жизненный цикл тикета: new -> accepted -> fixed. Нет отдельного статуса “in progress”. Нет статуса “тикет выполнен и передан на контроль качества”. Нет возможности настраивать жизненный цикл. Кроме того, наш текущий проект сильно выиграл бы от поддержки еще одного-двух дополнительных статусов.
Тоже мне проблема… Вместо “in progress” используем статус “accepted” (который нам по прямому назначению не нужен). Все остальные статусы вообще отображаются добавлением к тикету соответствующих комментариев. В результате имеем более-менее решенные проблемы поддержки нужных функций. При этом не надо писать не строки кода, не надо выбирать менее удобную в основных функциях систему, не надо страдать от полного отсутствия нужного функционала.
Другой пример. Посмотрим на комментарий, подтолкнувший меня к написанию этого поста:
# Алексей says: Я вот обнаружил, что для моего проекта Trac не очень подходит, а хотелось бы, т.к. интерфейс действительно удобный. В Trac понятия “version” и “milestone” привязаны к проекту целиком. В моём же проекте есть тесно зависимые по документации, но сильно отличающиеся по срокам релиза/версиям части. Поэтому, хотя Trac и поддерживает несколько проектов на одном компьютере, и даже исходники никто не мешает хранить в одном репозитории, я не могу пользоваться Trac, т.к. документация и тикеты не могут быть общими на несколько проектов, а версию/дату релиза невозможно сделать разными для частей одного проекта.
В данном случае, речь, очевидно, идет о необходимости отслеживания нескольких параллельных цепочек версий. Поскольку Trac этого не поддерживает, Алексей считает что Trac не подходит для этого проекта.
Позволю себе не согласиться. Кто мешает включить название или код “части системы” в имена Trac\’овских версий и Milestone\’ов? Да, это не так удобно как возможность включать в проект несколько параллельно идущих подпроектов, но пользоваться системой с неудобным интерфейсом гораздо хуже.
Сколько стоит неудобный интерфейс
Давайте посчитаем. Предположим, что у нас есть две багтреккинговых системы на выбор. В первой любая операция с багом (создание, назначение, комментирование, закрытие и т.д.) из-за плачевной юзабилити занимает на 3 минуты больше чем во второй (я сталкивался и с большими различиями). Возьмем небольшой проект: 4 человека. Среднее количество новых багов и задач за неделю будет в районе 40 штук. Пусть за весь жизненный цикл над багом совершается в среднем 4 операции: создание, назначение разработчику, исправление, проверка исправления. Потери времени, вызванные неудобным UI, будут равняться 40 x 4 x 3 = 480 минут в неделю. Это два часа на каждого члена команды! Я даже не считаю здесь потери, вызванные раздражением участников команды от того, как неудобно пользоваться багтреккингом, хотя можно предположить, что они тоже немаленькие.
Сколько стоит отсутствие нужной функции
Предположим, что наша багтреккинговая система не поддерживает какую-то нужную функцию, например, статус “in progress”. Для чего может быть нужен этот статус? Только для формирования отчета о выполняющихся в настоящий момент задачах. В зависимости от проекта этот отчет используется от пары раз в неделю до десятка раз в день. Допустим, что мы заменяем статус “in progress” статусом “assigned”, которым иначе бы не пользовались. В этом случае потери времени невелики - нужно просто научить всех участников проекта пользоваться одним статусом вместо другого. Теперь предположим, что мы вынуждены добавлять дополнительную информацию в название багов, а затем формировать отчет в полуавтоматическом режиме, что помимо потери времени на обучение ведет к потере 3 минут при каждом просмотре отчета. Если отчетом пользуются 5 раз в неделю, то мы теряем 15 минут за неделю, если 50 раз - порядка 150 минут за неделю.
Очевидно, что в приведенном примере замена более удобной системы на более функциональную является чистым проигрышем времени.
Подведем итоги
Несоответствие технологического процесса и используемых инструментов является широко распространенной проблемой. Основных решения три: менять инструменты, менять технологический процесс, приспосабливаться к наличию несоответствия. Первые два решения требуют весьма затратных изменений. Надеюсь, у меня получилось доказать, что это далеко не всегда оправдано.
Есть замечательный инструмент, который обеспечит вас “базовым набором” для управления проектом. Я говорю о 
