менеджмент


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

Через два года Вася стал владельцем основателем Pushkin Soft, ltd. и занимается продажей пасьянсов. Доходы позволяют нанять второго программиста, Петю, и с удвоенной энергией взяться за следующую версию продукта. Сначала Вася с Петей просто обсуждали планы работ устно. Но через некоторое время задач стало больше, возросшее количество клиентов заставило больше отвлекаться на техподдержку и друзьям стало ясно, что держать список работ в голове больше нельзя – постоянно что-то забываешь. Последней каплей стало то, что Вася забыл закрыть период бесплатной раздачи продуктов на сайте компании (по замыслу трехдневный) и две недели счастливые пользователи могли скачать бесплатную версию. Для решения проблемы была закуплена и повешена на стену огромная доска, на которую теперь записывались все планируемые работы. Выполненные работы стирались и места на доске вполне хватало.

Через год в компании работало уже 5 человек, и все стены были завешаны досками. Место на доске начало быть дефицитом. Кроме того, никто не мог вспомнить, какие работы были выполнены всего месяц назад. Вася понял, что так больше продолжаться не может и надо искать новое решение для записи задач.

Итак, перед Васей, как и многими другими на его месте, встал вопрос: что использовать для планирования, когда на доске и в голове кончилось место.

Многие первым делом обращаются к Microsoft Project. Мне хотелось бы предостеречь вас от совершения этой ошибки.

Project не поддерживает нужную вам модель данных

Основные объекты предметной области: задачи и исполнители в Project’е совсем не похожи на действительность разработки программного обеспечения. Значит, вам придется изворачиваться и придумывать, как запихнуть в это прокрустово ложе нужные вам данные. Это вполне реально и даже немного весело, но заставляет вас делать не очень нужную работу. В этом разделе я попробую описать основные недостатки модели данных Microsoft Project применительно к планированию процесса разработки. Со всеми этими проблемами я сталкивался лично и лично придумывал обходное решение.

  1. Project рассчитан на меньшее количество задач, чем вам нужно. Средний документ, вероятно, содержит меньше ста задач. Для управления проектом это смешная цифра. Для сравнения: в базе задач Apache Foundation более 40,000 записей, в базе Mozilla Foundation – более 360,000. В моем последнем проекте, очень небольшом, общее количество задач за 4 месяца достигло 200. В двухлетнем проекте, в котором участвуют 10-15 человек, количество задач может легко перевалить за 10,000. Я видел, как ведет себя MS Word на несвойственных для него объемах (сотни страниц технической документации со схемами) – падения, мистические глюки, тормоза. Лично не проверял, но могу предположить, что с Project’ом ситуация будет похожей.

  2. Project позволит вам случайно поменять ID задачи. Более того, есть целый ряд операций, которые при своем наиболее естественном исполнении ведут к смене ID задач. Будете вводить собственную систему ID/кодов? Будете использовать название и время от времени путать задачи с похожими названиями?

  3. Надо что-то делать с жизненным циклом задачи. Даже в самом простом случае вам придется иметь дело с циклом “выполнение -> проверка -> доработка -> проверка”. Заметьте, что за разные этапы отвечают разные люди. Как представить это в Project?

    • Можно разбивать каждую задачу на X подзадач – по одной на этап жизненного цикла. Получается громоздко и неудобно, зато относительно точно.
    • Можно назначать задачу сразу всем задействованным исполнителям – разработчику, тестировщику, аналитику, админу и т.д., и добавить к задаче поле “статус”, чтобы понять на каком этапе жизненного цикла эта задача находится. Хорошо, а как тогда отслеживать историю изменения статуса (она же не обязательно линейная)? Как понять, что функция возвращается на доработку четвертый раз, а не первый? Не знаю. В результате и так плохо и эдак нехорошо.

Итого: половину информации о проекте удастся внести в Project, вторую половину придется держать в голове.


Лирическое отступление номер 1. Опасные иллюзии или в чем отличие строительства дома от создания программного продукта

В рамках нашего школьного курса по MS Project учебным проектом, который нужно было описать, служила постройка дома. Мы описывали задачи, устанавливали зависимости, находили критический путь, переставляли задачи, оптимизируя общую длительность проекта, считали нагрузку на ресурсы и общую стоимость, снижали ущерб от срыва сроков… В общем, делали в воображаемом проекте все то, для чего предназначен Porject. Все тот же учебный проект, с небольшими вариациями, использовался в университетском курсе. Похожие примеры – в половине учебных материалов, лежащих в Сети. Эти примеры выбраны не случайно. MS Project затачивался на определенный тип проектов, и именно такие проекты и стараются использовать при обучении.

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

Итак, самые опасные иллюзии, заложенные в MS Project:

  • Исполнители взаимозаменяемы. В типичном учебном проекте в качестве исполнителей фигурируют 2 каменщика, 4 разнорабочих, сантехник, электрик, 3 маляра и 1,5 землекопа. Исполнителей каждого типа, как правило, несколько. Предполагается, что все исполнители одного типа одинаковы. Вы можете перераспределять их с одной работы на другую, делать одну работу силами нескольких исполнителей для ее ускорения и т.д. В разработке программного обеспечения все не так. Все участники проекта уникальны и слабо взаимозаменяемы. Если вы передадите наполовину сделанную Васей задачу Кате – она может потратить несколько дней только на то, чтобы разобраться, да и то если ей знакомы все задействованные языки, технологии и библиотеки. Project не может хранить информацию об этой зависимости и вам придется держать ее в голове. Другой пример – Катя может работать вдвое продуктивнее Пети и втрое продуктивнее Оли (вполне типично даже в небольшой команде). Соответственно, длительность выполнения задачи зависит от того, кто ее делает. Это тоже придется отслеживать вручную.

  • Для частично выполненной задачи можно правдоподобно оценить процент выполнения. Например, идет отделка комнат, выполнено 60%, осталось 40; мы опережаем план на два дня. Благодать… Жаль, что такие рассуждения применимы только к отделочным работам. В разработке софта задача, выполненная на 80% – не выполнена! Выполненная на 99.9% – тоже не выполнена. Сколько времени займет оставшаяся десятая процента можно узнать только после того, как работа будет закончена и сдана. Часто окажется, что 99,9% в действительности означало только 33,3%. Так уж сложилось, что получить правдоподобную оценку степени готовности можно только для некоторых работ, да и то от очень немногих людей. Поэтому здравомыслящий менеджер использует бинарную систему оценки готовности: готово – не готово. Всякие проценты – это, как правило, мишура, отвлекающая от более важных вещей.

  • Зная оценочную длительность всех работ, можно достаточно точно предсказать длительность всего проекта. Это подвид предыдущей иллюзии. Даже если вы можете безошибочно оценить длительность задачи (уже сомнительно), то у вас нет ни малейшего представления о том, сколько времени займет проект целиком. ДеМарко пишет, что в абсолютном большинстве случаев срыв сроков вызван непредусмотренными в плане задачами, а не ошибками в оценке длительности предусмотренных. С ним сложно не согласиться. Кроме того, в большинстве коммерческих проектов сроки определяются бизнес-соображениями, а не оценочной длительностью. И ваша задача – не оптимизировать длительность полной реализации плана, а поставить разумный набор функций, который удалось реализовать в срок. Кстати, выбором самых приоритетных задач Project тоже не позволит вам управлять. Как, например, исключить задачу из плана, не удаляя ее? В issue-tracking’е вы можете использовать wontfix. А в Project?


Issue tracking – специализированные системы для управления задачами в проектах связанных с разработкой ПО. Этот класс систем эволюционировал из систем отслеживания ошибок (багтреккинга) – оказалось, что жизненный цикл исправления ошибки весьма похож на жизненный цикл любой другой задачи, а объединение багтреккинга и планирования позволило иметь в одном месте весь список необходимых работ.


Project не поддерживает совместную работу

Хорошо, допустим, у вас получается вести актуальный список работ в MS Project. Вероятно, участники проекта слабо владеют телепатией. Значит надо как-то сообщать им о появляющихся задачах, а они, в свою очередь, должны как-то сообщать о сделанных работах. Как?

  1. Можно рассылать задачи в письмах, копируя описания из MS Project. Трудоемко и совсем не изящно. Теоретически, можно попытаться автоматизировать эту операцию с помощью VBA-скриптов в MS Project. И да поможет вам бог, если вы на это решились…

  2. Можно сообщать устно. Мало кто способен запомнить все несколько десятков задач, висящих на нем – это просто за пределами человеческих возможностей. Поэтому, когда пройдет изначальный период хаоса, работать устная раздача заданий будет следующим образом: вы записываете задачу в project, связываетесь с программистом и рассказываете на словах, что ему нужно сделать, он, находясь в середины выполнения другой задачи, чертыхается, уточняет формулировку, записывает новую задачу себе на листочек или в Outlook, потом пытается мучительно вспомнить, на каком месте текущей задачи он остановился. Через три дня (три недели, три месяца и т.д.), когда дело дойдет до новой задачи, программист отыщет свои записи, и попытается вспомнить, что же имелось в виду. В половине случаев он позвонит вам и спросит еще раз. В половине оставшихся – не позвонит, но его интерпретация задачи будет заметно отличаться от вашей. Каждый раз, когда вы прервете человека в середине задачи и бросите на какую-нибудь авральную работу, сцена с менеджером, листочком и телефоном повторяется. Примерно через две недели кто-нибудь потеряет свой листочек с заданиями, и они с менеджером будут мучительно пытаться понять, какие же задачи потеряны, а какие – нет. А через некоторое время у одного из участников накроется жесткий диск, унося с собой в могилу все его данные, после чего операция с диктовкой 40 актуальных задач повторяется.

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

Итого: главным инструментом вашей совместной работы над планами станет телефон. Оно вам надо?


Лирическое отступление номер 2. MS Project Server

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

Типа.

В одном проекте мы, наткнувшись на сложности совместной работы на базе документа, честно пытались пользоваться Project Server’ом. Не получилось. Продукт оставляет ощущение недоделки, скорость работы в локальной сети заметно медленнее, чем большинство хороших issue tracking систем в Интернете (с сервером на другом континенте). Все остальные проблемы, которые уже забылась, но они были, и весьма неприятные.

Так что рекомендую пользоваться Project Server только в качестве эксперимента.


Что-то хорошее

Чем Project хорош – так тем, что, пользуясь им, нельзя не увидеть “С начала проекта прошло уже два месяца. Осталось полтора, а мы еще ничего толком не сделали… Вот дерьмо!”. Если ваш инструмент позволяет, заведите себе такой индикатор прошедшего времени и повесьте его туда, где он будет бросаться на глаза.

Резюме

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

Если не Project, то что?

Если у вас нет опыта использования Issue Tracking, в небольшом проекте я бы рекомендовал начать с использования Excel. Затраты на установку и обучение минимальны, поэтому вы сможете сосредоточиться на содержательной стороне Issue Tracking’а и понять какие задачи он должен решать для вас. Через некоторое время вы сможете гораздо более осознанно выбрать Issue Tracking систему, чем выбрали бы с самого начала.

Во всех остальных случаях просто найдите нормальную Issue Tracking систему и пользуйтесь ей.

Интересно, а пользуются ли в Microsoft своим Project’ом для планирования процесса разработки?

Update: из чего выбирать свою первую issue tracking систему

Приведу небольшой перечень хороший вариантов для выбора в качестве первой issue tracking системы:

  • Trac – очень удобен в использовании, помимо issue tracking’а включает тесно интегрированную с ним wiki. Существует множество плагинов, расширяющих функциональность. Базовая функциональность в области issue tracking не очень богата, в больших проектах с сильно формализованным процессом разработки ее может не хватить. Open Source.

    В настоящее время я использую Trac, очень доволен.

  • Jira – многофункциональная issue tracking система. Продуманная поддержка как bugtracking так и project management функциональности. Весьма удобна в использовании, хотя и не дотягивает в этом показателе до Trac. Коммерческая, цены начинаются от $1200/сервер.

    Мы использовали JIRA около 4 месяцев, довольны всем, кроме цены.

  • Bugzilla – проверенная временем система с достаточной функциональностью, но без особых изысков. Отличная надежность, масштабируемость и производительность. Open Source.

  • Mantis – еще одна неплохая система. Open Source.

Более подробные обзоры и сравнения систем можно найти на сайте software-testing.ru(они часто концентрируются в своих обзорах на багтреккинговой части функциональности) или на википедии.

Материалы по теме

« Previous PageNext Page »