LXF144:projects
|
|
|
Содержание |
Управление проектами на примере проектов сообщества открытого ПО
- Джоно Бэкон делится опытом и советами по ведению проекта открытого ПО или сообщества.
Мир открытого ПО полнится знаниями — в области не только создания открытого кода, но и планирования мероприятий, написания документации, создания дизайна и художественных работ, тестирования и многого другого. Мы — сообщество азартных, талантливых личностей, применяющих свои умения на общее благо. Так возникают тысячи проектов, подкрепленных разного сорта навыками и охватывающих все возможные интересы.
В кипении проектов, творчества и энтузиазма иногда настает хаос. Хотя многие преуспевают в искусстве создания кода, организации мероприятий или по сходным качествам, не каждый одарен в тонком искусстве успешного ведения проекта. Есть несметное число примеров разболтанной группы хакеров, собравшихся вместе работать над проектом и в итоге утративших цель, четкие сроки сдачи и понимание функционирования проекта в целом. Плохо управляемый проект не только неэффективен в плане доставки результата пользователям, но и отпугивает добровольцев. В какой проект вы бы вошли: тот, где никто не ведает, что творится, и неясно, чем заняться, или тот, где точно сформулировано, чем вы сможете помочь и как ваш вклад вольется в проект?
Поэтому вот вам первое практическое правило данной статьи: для лучшего управления проектом откажитесь от мысли, что вам известно, что вы делаете. Конечно, часть ваших действий будет иметь смысл, но лучше настроиться на приключение, предположив, что есть мир неизведанных технологий управления проектом, и изучая их, вы найдете жемчужины, которые позволят вам добиться успеха. Величайшие менеджеры проектов – это те, кто всегда готов сменить свои методы и подходы на более достойные, с которыми лучше работается, и помочь всем участникам проекта провести время приятно и с пользой.
В нашей статье мы обсудим ряд подсказок, технологий и подходов к выполнению проекта. Эти предложения применимы к проектам любого типа, не только к разработке ПО, хотя, конечно, основной упор будет на ней. Для проекта другого типа просто смените терминологию, и совет будет отвечать вашим нуждам (например, если вы готовите встречу, то вместо Релиза у вас будет стоять Мероприятие)
Как мы вывели из материала прошлого номера Работа вашей мечты, LXF143, опыт участия и управления проектами открытого ПО – прекрасный пункт в вашей биографии или резюме, и методики статьи направлены на это. Если вы сумеете предъявить сильные, организованные и подтвержденные качества руководителя проекта, все работодатели будут ваши. Итак, пристегните ремни безопасности – выезжаем на трассу хорошо управляемых проектов.
Ключ — планирование
Ключевыми моментами в успешном управлении проектом являются a) организованность, b) задание ожиданий, и c) убеждение людей поверить в ваш проект и вступить в него. К счастью, начав с пункта a, вы попадете в пункт b, а тот, в свою очередь, вдохновит вас на пункт c. Другими словами, хорошая организованность помогает задать цели и убедить людей поверить, что ваш проект стоит участия. Для достижения этого требуются три положения:
- Видение Всегда хорошо представлять, к чему вы стремитесь. Это могут быть функции вашей программы, докладчики на собрании, количество требуемой документации, и т. д.
- Планирование Разработайте план действий по достижению цели в заданное время и по распределению работы между имеющимися членами команды.
- Слежение за прогрессом Обеспечьте, чтобы команда регулярно продвигалась к намеченным вами целям, согласно плану проекта.
Нырнем же в каждую из этих областей и исследуем, как добиться наибольшего прока от вашего проекта.
Видение
Решить, что вы хотите сделать, звучит проще, чем есть на самом деле. Определяя жизнеспособность функции, нужно оценить не только то, хватит ли вашей команде умения для ее воплощения, но также объем трудозатрат, чтобы завершить ее одновременно со всем остальным. Также нужно убедиться, что определив цель, вы сплотите команду вокруг этой цели и предотвратите дублирование усилий. Планирование также эффективно устанавливает ожидания у потребителей вашего труда (пользователей программы, посетителей мероприятия и т. п.).
Чтобы определиться, над чем именно вы хотите работать, нужен открытый диалог с командой. Оптимизируйте его – пусть все члены команды чувствуют, что они могут сказать свое слово. Постарайтесь избежать впечатления, что цели и задачи раздаете вы. Здесь лучший подход – провести серию встреч, чтобы каждый внес свою идею, а вы сформируете из них план, с широким представлением, кто чем занимается.
Проводя встречу, четко обозначьте, что идеи приветствуются и добавляются в план, если люди берут на себя эту работу плюс помощь по идеям других. Ваш долг лидера – не только соблюдать это правило (поскольку рой идей, не привязанных к исполнителям, бесполезен), но также не слишком загружать добровольцев. Иначе вы получите в результате много задач, законченных наполовину.
Все знают, что такое списки to-do. Кому-то они нравятся, а кто-то их всей душой ненавидит. Пусть вы и не фанат таких списков, но если вы забывчивы, список принесет пользу в сопровождении проекта.
Самое важное требование для успешного списка – простое, быстрое и эффективное добавление пунктов. Для поддержания списка в актуальном виде мы горячо рекомендуем прекрасную утилиту под названием Getting Things Gnome (http://gtg.fritalk.com). В ней можно добавлять пункты, устанавливать сроки завершения, проставлять метки, чтобы задачи группировались по категориям, и даже синхронизировать ваш список с сайтами типа Remember The Milk (http://www.rememberthemilk.com), чтобы ничего не потерялось.
На встрече документируйте эти планы с помощью следующего шаблона, который поможет вам четко определиться с видением проекта:
- Задача Укажите цель.
- Критерий успеха Приведите утверждение, на которое можно ответить «да» или «нет», определяющее, выполнена ли работа.
- Действия Добавляйте действия высшего уровня. Не следует мельчить; подробности появятся позже. Действия не обязательно назначать каждому.
- Срок Когда вы хотите завершить проект.
- Спецификация Более детальное описание цели и как она сформировалась.
- Владелец Человек, который будет координировать всех участников проекта.
Наличие этих целевых блоков создаст вам твердое представление о целях проекта и координаторах для каждого из блоков задач.
Планирование
Следующий шаг – разделить все цели на набор действий, приписанных различным членам команды, и поместить соответствующий документ в более-менее общественном месте. Он может быть простым, типа wiki, или сложным, например, утилитой управления проектом. Первичная задача здесь – позаботиться о разбиении каждой цели на простейшие действия, разделяющие всю работу на управляемые фрагменты.
При разработке действий рекомендуется следующее практическое правило: на завершение действия не должно уходить более полдня. Ведь большинство членов вашей команды – добровольцы, и если завалить их тоннами заданий, все и будет завалено. Если действия небольшие и их можно завершить за вечер после работы, выполнение будет вероятнее.
К концу этого шага у вас должен быть набор целей в одном документе и другой документ, со всеми действиями. Сейчас вы в положении, когда вся работа согласована и роздана исполнителям. Хороший лидер должен пройтись по плану еще раз и убедиться, что никто не перегружен работой. Если это так, спросите, можно ли передать некоторые действия другим, рассредоточив нагрузку.
У большинства менеджеров команд есть набор наработанных методов и технологий, и они могут быть полезны при работе с сообществом проекта открытого ПО. Одна из таких областей – проведение встреч.
Предположим, что ваша встреча проходит в двух основных средах: публичные встречи в ретранслируемом интернет-чате (Internet Relay Chat – IRC) и на конференциях. Проведение встреч такого рода будет немного отличаться, но у каждой есть главная цель: собрать со всех точки зрения и прийти к согласию насчет действий, необходимых для движения вперед.
Проводя встречу, вы должны в первую очередь позаботиться о повестке дня и о возможности добавить в повестку новый пункт для каждого участника. В проекте открытого ПО этого удобно достичь, создав публичную страницу wiki, где можно добавлять пункты в повестку дня. Не надо соблазняться и пропускать сведение повестки, даже если пунктов мало. Повестка дня убедит всех, что собрание будет дельным.
Затем пройдитесь по всем пунктам повестки, один за другим, поддерживая разговор, убеждаясь, что каждый имеет возможность высказаться (проследите за застенчивыми участниками – постарайтесь при случае сами передавать им микрофон, если им неловко прерывать разговор). Пройдя по всем пунктам повестки, побудите команду к действиям, затем удостоверьтесь, что все задачи назначены и согласуются со установленными сроками сдачи (зачастую это делается на следующей встрече, если таковые проводятся регулярно).
По окончании встречи составьте список действий и поместите его в общедоступное место, где его видят все, кто присутствовал на встрече. Практика управления проектом показывает, что если действия назначены публично, это дисциплинирует людей, увеличивая вероятность выполнения задач. Утилита заметок Tomboy (см. Полезные утилиты) – удобный инструмент для отслеживания действий.
На следующей встрече обязательно сделайте обзор действий с последней встречи, чтобы увидеть, все ли сделано, опознать препятствия или проблемы или, за отсутствием таковых, продолжить.
Слежение за прогрессом
С набором целей и детальных действий, готовых к старту, ваша команда снабжена всем необходимым для реализации проекта. В идеальном мире ваш любовно выработанный план достаточен, чтобы оставить команду спокойно работать и получить готовый проект в срок. Но вряд ли будет сюрпризом узнать, что такое бывает крайне редко. Каждый большой проект имеет большого лидера, который отслеживает прогресс, проверяя, все ли закончили свои задачи, расшивает узкие места и следит, чтобы команда не унывала.
В проектах открытого ПО между моментом, когда все взяли на себя задания, и датой сдачи может произойти масса изменений. Люди женятся, болеют, берут отпуск, теряют свою основную работу, занимаются другими делами, заводят детей и попадают в другие жизненные ситуации, затрудняющие их участие. Но это не повод считать, что из-за них ваш проект сорван; просто передайте работу кому-нибудь другому, у кого достаточно времени и квалификации для участия в проекте.
Справляться с подобными непредвиденными обстоятельствами – значит иметь a) отличное видение завершенной работы и b) хорошее чувство того, кто над чем работает – где гибкие места, а где проблемы. Существуют утилиты, способные помочь вам с a, одну из которых мы обсудим ниже (см. Диаграмма догорания), но b включает проведение времени с командой, обзор текущей работы, да обычно и пребывание в той части группы, которая органично работает и взаимодействует. При хорошем видении проекта и людей вы сможете гарантировать успешное завершение, невзирая на непредвиденные обстоятельства.
Делиться опытом
Перенимание опыта других людей и опробование новых техник – лучшие способы развить и усовершенствовать собственные навыки. Прекрасный шанс для этого – спросить людей, как они управляют проектами, и изучить их подходы. Раз так, я решил, что будет полезно показать вам, как я управляю командой из Canonical: эти методы могут пригодиться в ваших проектах и ваших командах.
Ubuntu Community Team состоит из четырех человек: Даниэля Холбаха [Daniel Holbach], Хорхе Кастро [Jorge Castro], Давида Планеллы [David Planella] и Ахмеда Камаля [Ahmed Kamal]. Совместно эта команда работает над проектами сообщества. Эти проекты способствуют росту, новым возможностям и производительности в сообществе Ubuntu. Я управляю командой, разбивая шестимесячный цикл релизов Ubuntu на серию задач по управлению проектом:
- Сбор требований
- Планирование целей
- Запуск работы
- Отслеживание прогресса
Некоторые думают, что работа над большим проектом открытого ПО состоит просто в том, чтобы следить за выполнением всех работ в срок. У хорошего лидера есть, однако, другая ключевая функция: быть вместе со своей командой, когда она в вас нуждается.
Всегда важно помнить, что участники большинства проектов открытого ПО – добровольцы. У них есть семьи, ответственность, интересы в других областях, основная работа и другие сферы жизнедеятельности, препятствующие их вкладу. И они – живые люди: у них есть чувства и эмоции, они испытывают стресс и перегорают, тревожатся и волнуются и не хотят выглядеть в сообществе глупо.
Раз так, всегда учитывайте тот факт, что команда – не просто механизм, выполняющий работу, и регулярно проверяйте, все ли у людей в порядке. Если вы заметите стресс или напряженность, скорее всего, в их жизни произошло нечто, вызвавшее такую реакцию. Тут уместно по-дружески спросить, все ли в порядке. Идеальный менеджер проекта является организатором и другом; старайтесь быть и тем, и другим.
Первый шаг – сбор требований, который включает поиск того, над чем нужно работать сообществу и Canonical. В проекте открытого ПО это сродни пониманию того, чего хотят от программы ваши пользователи, или кого вы хотели бы видеть на мероприятии.
Тут требуется, чтобы я сделал несколько звонков, выслал электронную почту заинтересованным лицам (менеджер проекта говорит напрямую с теми, кто оказывает влияние на проект) или обратился к сообществу и выяснил, куда направить основные усилия команды. При этом нужна осторожность: бойтесь вызвать иллюзию, что они делают заказ на Рождество, а вы его доставляете. Дайте понять, что вам нужны эти данные для создания чего-то, что сделает жизнь лучше. Не каждый получит то, что хочет.
Обычно такой процесс приводит к появлению на странице wiki громадного списка с маркированными пунктами, указывающего на то, сколько всякого-разного хочется людям. Следующий шаг – расставить приоритеты в этом списке, выделив задачи, которые при текущих ресурсах достижимы за шестимесячный цикл релизов. При управлении проектом открытого ПО определитесь, чего, на ваш взгляд, можно достичь за данный временной интервал с данным количеством участников.
Это очень сложная задача. Если вы человек того же склада, что и я, вы будете пытаться сделать больше, чем позволяет ваше время, и здесь нужно принимать трудные решения. По мере моей работы со списком маркированные пункты преобразуются в целевые блоки, которые мы рассматривали ранее, и они тоже размещаются на странице wiki. Этот документ будет нашей дорожной картой. Страница служит двум полезным целям: помогает команде понять, на чем следует сосредоточить усилия, а также поясняет заинтересованным сторонам, чего ожидать от команды на данном цикле релиза.
Имеется немало утилит, способных помочь вам успешно организовать проект, от управления списками to-do до программ для совместной работы. С их помощью вам не надо будет беспокоиться о поддержании действий вашей команды. Стоит обратить внимание на следующие:
- Tomboy
http://projects.gnome.org/tomboy
Простое и эффективное приложение для заметок, удобное для записи задач и быстрых напоминалок.
- Getting Things Gnome
Как упоминалось ранее, это чертовски простая утилита управления списками to-do. GTG полезна для отслеживания всего, касающегося вашего проекта, и для ежедневной самоорганизации.
- Launchpad
Хотя кузниц для разработчиков полным-полно, лучшая из них – Launchpad – предоставляет самый качественный хостинг для кода, поиска ошибок, отслеживания плана-копии и многого другого.
- The Art Of Community, автор Джоно Бэкон
http://www.artofcommunityonline.org
(Признаю: здесь мне сложно быть непредвзятым...) Эта книга о том, как собрать и организовать сообщество. Хотя ее можно купить в бумажном варианте, она также бесплатно доступна на условиях Creative Commons. Она битком набита материалом по теме этой статьи.
Дорожная карта удобна для просмотра задач, над которыми бьется команда, но ее недостаточно, чтобы группа разобрала проекты на более мелкие куски для планирования своей работы На этом этапе Давид Планелла, координатор Ubuntu Translations, хотел запустить серию сеансов тренинга переводчиков. Четырех пунктов на карте про эту задачу не хватало для планирования работы, и он разбил ее на такой набор действий:
- Сделать запись в блоге, приглашающую сообщество дать обратную связь по темам, которые они хотели бы видеть в сеансах тренинга, и принять участие в этих сеансах.
- Создать имя http://wiki.ubuntu.com/Translations/Training для информации, связанной с сеансами тренинга.
- Записать документ в Ubuntu wiki со списком тем, желательных в сеансах тренинга.
- Выбрать несколько тем оттуда для сеансов тренинга переводчиков и приготовить набросок для каждого из них.
- Создать проект Launchpad (http://www.launchpad.net) в качестве площадки для сеансов тренинга переводчиков.
- Начать сеансы тренинга переводчиков согласно выбранной схеме.
Наряду с не перечисленными здесь задачами, каждое из этих действий было приписано разным людям, включая членов сообщества, и Планелла гарантировал, что все завершится к концу шестимесячного цикла разработки.
В каждом проекте команда регистрирует план-копию на Launchpad и добавляет туда список пунктов. План-копия также предоставляет другие полезные функции, такие как назначение, кому предназначен план-копия, состояние текущей реализации и конечная дата для завершения. Также это позволяет подписку для зрителей, то есть при любом изменении плана-копии (например, обновлении в действии) они получают электронную почту с уведомлением. После этого процесса у нас будет набор планов-копий, один для каждого проекта, а вся работа будет разбита на действия, и все сроки сдачи четко обозначены.
Диаграммы догорания
Хотя в этом пункте все выглядит подготовленным, у менеджера проекта еще много работы. В команде может быть до 50 планов-копий, и помочь команде гармонично работать с этакой кучей действий в 50 планах-копиях, чтобы все было сделано в срок – тяжелый труд. К счастью, у нас есть прекрасная технология для отслеживания этой работы.
Диаграмма выгорания
Первичный компонент успеха проекта – это не только знание того, кто над чем работает, но также и того, к какому сроку нужно закончить каждое действие. Поэтому настоятельно рекомендуется составить календарь важных дат (известный также как план релиза), где отмечены все сроки на всем расписании.
Например, пусть вы хотите организовать мероприятие; тогда план может иметь следующий вид (для наших целей мы взяли упрощенный список дат):
- 5 янв Начать поиск места проведения.
- 20 янв Закончить поиск места проведения.
- 25 янв Сделать объявление о событии.
- 1 фев Объявить о приеме докладов.
- 5 фев Начать поиск спонсора.
- 20 мар Конечный срок поиска спонсора.
- 23 мар Последнее подтверждение спонсорству.
- 1 апр Закрыть прием докладов.
- 10 апр Объявить список докладчиков.
- 22 май Событие.
Если вы составляете план релиза проекта ПО, а не мероприятия, у вас будут стоять сроки для таких событий, как Заморозка интерфейса пользователя, Заморозка функций, Альфа 1/2/3, Бета 1/2, релиз-кандидат и т. д.
На сайте https://wiki.ubuntu.com/NattyReleaseSchedule находится расписание для Ubuntu 11.04 Natty Narwhal – это пример хорошего расписания релиза ПО.
Эта технология называется «диаграмма выгорания» [Burndown chart] (см. Рис. 1). Мой коллега Мартин Питт [Martin Pitt] написал программу, которая берет все действия, занесенные в планы-копии команды, и выдает график, показывающий их состояние. Когда команду просят поместить действия в план-копию, она добавляет его в стандартном формате, где указывается, кому приписано действие, и его состояние. Например, «[dpm] написать документ в Ubuntu wiki со списком тем, которые мы хотели бы охватить в сеансах для переводчиков: Сделано».
Здесь приведено действие, приписанное Давиду Планелле («dpm»), и он завершил это действие («Сделано»). Состояние действия может принимать значения To Do, В процессе и Отложенное.
Скрипт Питта считывает все пункты действий, вместе с приписками и статусами, и рисует диаграмму на Рис 1. По оси X отложена продолжительность 6-месячного цикла, по оси Y – полное количество действий в цикле. Каждый день на диаграмме появляется новая полоса, которая разделяет все действия на To Do [Надо сделать] (красный), Done [Сделано] (зеленый), Postponed [Отложено] (желтый) и In Progress [В процессе] (оранжевый). Из левого верхнего угла в правый нижний угол протянута жирная черная линия тренда. Задача менеджера – следить, чтобы красный цвет был ниже этой линии: это показывает, что во всех действиях происходит согласованный прогресс.
Диаграмма удобна для сбора большого числа наборов действий в удобочитаемую форму, отражающую прогресс всей совокупности работ. Это не только полезная награда для команды за успех цикла, но также и великолепный способ демонстрации прогресса другим. Естественно, такие диаграммы требуют регулярных обновлений. Вам нужно позаботиться о том, чтобы по завершению действия его статус своевременно менялся. Если не обновлять отражения статуса действий, диаграмма утрачивает смысл. Когда вы заведете привычку регистрировать действия, поддержание в актуальном состоянии перестанет быть неприятной обузой.
Заключение
Управление проектом и запуск успешного, организованного проекта – огромная тема, и ее нельзя уместить на шести страницах. Целью этой статьи было дать вам прикоснуться к некоторым важным концепциям и обеспечить некоторый контекст – воспользуйтесь им как трамплином для дальнейшего изучения предмета. Навыки эффективного управления проектом – непрерывная череда продвижений и опыта. Встречая людей, применяющих другие подходы, вы будете продолжать узнавать, что сработает для вас.
Если вы подружитесь с каким-нибудь лидером проекта, поковыряйтесь в их мозгах на предмет подходов, усвоенных ими уроков, ловушек, которые они сумели избежать, и другой ценной информации. Один из самых приятных свойств сообщества открытого ПО – желание передать свой опыт и наилучшие практики: во многих случаях стоит только попросить совета, и с вами радостно поделятся.
Удачи вам – и не забывайте и сами делиться своим опытом с другими. Сообщество открытого ПО разрастается, мы постоянно приглашаем новые поколения лидеров и участников, и нам всегда нужно стараться делиться с ними своей мудростью и рекомендациями. Помните об этом, наставляя новое поколение лидеров открытого ПО.
Поддерживайте разговор
Всегда обеспечивайте каналы связи, простые в обращении и операциях, чтобы новички могли легко присоединиться. Многие проекты потерпели неудачу из-за того, что не помогали новым участникам быстро втянуться.
Добивайтесь согласия в главном
Всегда лучше подходить к задачам по правилу «разделяй и властвуй», а это возможно, только если вся группа согласна с работой. Также старайтесь делить задачи между несколькими участниками.
Следите за задачами
Безнадзорные действия, как правило, оборачиваются бездействием, особенно в сообществах добровольцев. Еженедельно проверяйте каждого, убеждаясь, что все на связи, и искореняя все препятствия.
Сохраняйте спокойствие
Ваше терпение часто будут испытывать трудные участники, люди, не выполняющие обещаний, и т. п. Помните, что эти люди – добровольцы. Не срывайтесь на них, иначе они могут и не вернуться.
Распознавайте проблемы пораньше
Если возникли проблемы с завершением какого-либо действия, лучше обнаружить это заранее, чтобы успеть перепоручить его другому. А значит, нужно часто обновлять статусы действий и регулярно проверять их.
Поощрение — это важно
Наши сообщества состоят из добровольцев, обычно падких до признания, поощрения и благодарности за работу. Пусть они считают свой вклад весомым – тогда они будут оставаться с вами и дальше.
Всегда записывайте и публикуйте действия
Если вы проводите встречу и записываете действия, опубликуйте их как известие о том, чего команде ждать от следующей встречи. Это хороший способ следить за прогрессом.
Документируйте все подряд
Ключевым моментом в эффективном управлении проектом и в том, чтобы каждый знал свой участок работы, является документирование всех процессов, планов релиза и прочего, чтобы все было на той же странице.
Публичность встреч
Хотя звонки один на один иногда полезны, общее правило – стараться делать все встречи сообщества публичными. В сообществах открытого ПО все должно быть прозрачно.
Не бойтесь делиться нагрузкой
При запуске проекта иногда страшновато передать бразды правления и часть ответственности другому. Но бояться не следует. Наоборот, это снимет с вас клеймо душителя прогресса проекта.
Выдерживайте расписание релиза
Когда над проектом работает группа добровольцев, может показаться соблазнительным сделать срок сдачи релиза плавающим. Не поддавайтесь этому без крайней необходимости.
Учитесь у других
В сфере управления проектами учиться можно многому у многих, единого пути здесь нет. Спрашивайте других, как им удается справитсья; это поможет развитию ваших навыков.
Политика «нет — вредителям»
Люди, с которыми сложно иметь дело, причиняют большой вред сообществу открытого ПО, из-за них часто срываются релизы. Будьте справедливы, пытайтесь разрешить конфликт, но не поощряйте деструктивных личностей.
Эффективно следите за процессом
Лучше всего управляются такие проекты, где есть прекрасное видение, как хорошо все работает. В этой статье мы рассказали о диаграммах догорания – найдите такую систему, которая лучше подходит для слежения за вашим проектом.
Не игнорируйте инструменты
Многие проекты начинают с изобилия утилит управления проектом, которые со временем игнорируются. Используйте эти утилиты по назначению: помочь вам достигнуть большего.
Не будьте бюрократом
Инструменты и процессы нужны для того, чтобы люди работали эффективнее. Если есть способ быстрее или лучше выполнить задачу, стремитесь найти его, и не говорите, что «правила есть правила» – это вызовет только раздражение у участников.
Подбирайте задачи по силам
Одни умеют хорошо кодировать, другие – писать документацию, третьи – создавать художества. Всегда старайтесь дать людям подходящую для них работу. Это приведет к успеху.
Не игнорируйте контроль качества
Во многих проектах ПО фаза поиска ошибок и контроля качества (Quality Assurance, QA) слишком коротка, или же люди отвлекаются, пытаясь ввести побольше функций. QA – это самая главная предоставляемая функция; не дискредитируйте ее.
Отмечайте ошибки
По мере прогресса обязательно отмечайте критические и важные ошибки в релизах (например, в альфа-версиях) и убедите сообщество уделить им приоритетное внимание. Это поможет создать более прочный релиз.
Отражайте и переоценивайте
В конце каждого релиза оцените, хорошо ли проделана работа и где ее можно улучшить. Это здравый процесс для идентификации роста и совершенствования на будущее.
