Индустрия программного обеспечения зародилась в начале 1960-х с появлением компьютеров в образовательных учреждениях и крупных компаниях. С появлением персональных компьютеров в конце 1970-х отрасль стала переживать взрывной рост, который, по сути, продолжается уже более 60 лет. Помимо развития самих языков программирования, средств разработки, платформ в постоянном развитии находятся и методики управления разработкой программного обеспечения (Software Development Methodology- SDM). Практически каждый год появляются новые методики и подходы к программированию и организации совместной работы; на сегодня достаточно широко известны более 40 концепций. Некоторые методики становятся по-настоящему популярными, о них пишут книги, ломают копья в сетевых баталиях, проводят конференции, ну, и, соответственно, упоминание этих модных аббревиатур становится практически обязательным для указания в резюме.
Лет 10 назад, для того, чтобы тебя принимали за серьезного разработчика, нужно было обязательно говорить о свободном владении инструментами RUP(Rational Unified Process) и PMBOK(Project Management Body of Knowledge). Если ты себя позиционировал как супермодный хиппи-программист, то можно было указать в резюме о применении методик экстремального программирования (XP) и приверженности методики водопада при управлении проектами (waterfallmodel). Сегодня модно стало говорить о применении гибких методик управления проектами. Ключевые слова — пропуска в современный мир разработчиков теперь: Agile, Scrum, Kanban, LEAN. Включение названий данных методик в резюме обычного начинающего программиста автоматически превращает его в модного ХайТек-хипстера, который уже не «пишет код», а работает с командой над стартапом, в роли не меньше, чем Scrum Master.
Сейчас, как и 10 лет назад, модные методики постоянно на слуху, но мало кто углублялся в их суть глубже, чем прочитать статью в Википедии. Чаще всего для свободного овладения современным сленгом хватало общения на форумах, да и редкого присутствия на конференциях, где докладывал об успехах использования модной концепции тот, кто удосужился прочитать о ней чуть больше, чем статью в Википедии. Регулярное появление новых методик ведения софтверных проектов обусловлено не сменой сленга, они нужны не для того, чтобы отделить программистов-мамонтов от современного разработчика-хипстера, а реальной потребностью отрасли. Кто-то слышал о новых прорывных методиках ведения строительных проектов? Нет, индустрия капитального строительства существует уже достаточно давно, методики устоялись, и потребности в активном поиске новых решений уже нет. Прорыв, кончено, возможен, но скорее, как случайная находка. Можно сослаться на тысячелетнюю историю развития данной отрасли, на то, что софтверному бизнесу еще и 60 лет нет… Хорошо, индустрия бизнес и финансового консалтинга существует не так долго, сопоставимо с разработкой ПО, о каких новых методиках ведения бизнес-консалтинга вы слышали? Причина в том, что строительная отрасль хорошо регламентирована стандартами и нормами, они устоялись, общеприняты, есть методики разработки строительной технической документации. В консалтинговых проектах, например, нет общепринятых стандартов и норм, но у каждой компании есть набор наработанных шаблонов, методик, подходов, при помощи которых можно получить неплохой результат работы команды, на 80% состоящей из стажеров.
Продолжающийся поиск решения для проектов разработки программного обеспечения обусловлен одной ключевой проблемой — очень высоким уровнем неопределенности, при том, что неопределенность во всем, от того, что будем делать, до как это будем делать и что в итоге получим. Когда заказчик хочет построить новый дом, то он более-менее представляет, что хочет в итоге получить, исполнитель знает какими технологиями и материалами это можно обеспечить, ну и все хорошо понимают, что в итоге будет построено. Когда клиент заказывает новое программное решение, то, скорее всего, почти все из того что будет сказано изначально, будет так или иначе изменено. Для решения поставленной клиентом задачи можно придумать миллион разнообразных решений, от адаптации готовых решений, до разработки с нуля своего решения. А в финале, затратив пару лет и несколько миллионов долларов клиентских денег, можно столкнуться с тем, что требуемого результата так и не достигли.
Классические методики управления, во многом, адресованы для снижения рисков исполнителя, связанных с плохой постановкой задачи клиентом. Выполнение работ разбито на четкие этапы, сначала делается устав проекта, потом состав работ (ProjectScope), далее фиксируются все работы в иерархическом плане работ, потом диаграмма Ганта, ну и, самое важное, все отклонения строго документируют в заявках на изменение. При четком соблюдении такой методики утилизировалось много человеко-часов, и, соответственно, бюджета, получалось много документации, но мало готового продукта. Рисков для исполнителя мало, но клиент не доволен. Современные проектные методики предлагают разнообразные способы решения проблемы нечеткости изначальных требований клиентов. Можно использовать поэтапную разработку, принцип водопада или спирали, если отношения с клиентом хорошие, то можно гибкую — Agile. Так или иначе, у софтверной отрасли сегодня есть инструменты решения данной проблемы.
Инструменты работы с динамичными клиентскими требованиями есть и работают, но отрасль продолжает поиск новых методик разработки. Может есть еще фундаментальные не решенные проблемы? Гибкие требования, большой диапазон возможных задач, все приводит к сложности фрагментировать работы и грамотно организовать командную работу. Классические методики предлагали сначала создать документ Требования к продукту (Product Requirements Document), потом провести анализ и приоритизацию задач, далее по каждому пункту создать функциональную спецификацию, к ней тест-кейс, и только потом отдать в разработку. Хорошо прописанные функциональные спецификации можно было распределить на разных программистов. Проблема была только в том, что часто нужно потратить времени на создание спецификации не меньше, а то и больше, чем на само написание кода. Современные методики, например, Scrum, предлагают решать эти задачи лучшей организацией командной работы, больше времени тратить на коммуникации, больше времени тратить на совместное обсуждение планируемых подходов к решению, ежедневными 15 минутками и т.д.
Улучшение коммуникаций с клиентом, переход на личные, фактически неформальные, коммуникации, позволит быстрее получить готовый продукт при продолжающемся непрерывном потоке клиентских «хотелок». Но у этого решения есть и цена — риски, если вдруг что-то по проекту пойдет не так, то, грубо говоря, бумажками прикрыться не получится. Отказ от формального и детального описания работ и переход на командную работу, обострил другую проблему, фактически, современную эпидемию — дефицит внимания. Все как-то забыли, что продукт — то, что несет в себе клиентскую ценность, получается не в результате обновления бэклога, ни на совещаниях, а после написания кусков работающего кода. А для того, чтобы написать этот код, нужно создать уникальный продукт, это как небольшое, но изобретение, что-то новое, чего раньше не писали или не делали. Даже если задача стоит вполне тривиальная, то создаваемое программистом решение будет вполне уникальным в своем роде. Как можно помочь разработчику быстрее найти самое лучшее решение поставленной задачи? Да, просто не мешать ему, дать возможность сосредоточиться и полностью сконцентрироваться над задачей. Но как это сделать, когда все сидят друг у друга на голове, постоянно кто-то с кем-то говорит, регулярно проходят какие-то короткие совещания… У каждого действия есть противодействие, у каждого лекарства — побочные эффекты. В данном случае современные методики типа Scrum«лечат» одно, но «калечат» другое, не менее важное — возможность полностью погрузиться в написание кода.
Широко используемая методика спринта (Scrum-sprint) предлагает устраивать краткосрочные, от одного дня до месяца, марафоны. Намечать планируемые результаты и буквально, как солдаты бросаться в атаку, чтобы занять следующую высоту. Секрет в том, что ни каждый командир сможет поднять солдат в атаку, а для организации успешного марш броска нужен еще более опытный командир. Такие методики работы в режиме «аврала» возможны, но они не работают в режиме правила. Невозможно долго работать в режиме маленького подвига, у людей начинает вырабатываться толерантность и каждый новый спринт все сложнее становится организовать, да и люди устают, выгорают и начинают искать другую работу. Решение этой проблемы я предлагаю искать в области психологии. Основная задача, получается в том, чтобы помочь разработчикам войти в состояние потока «flow», а для этого нужно добиться того, чтобы как можно меньше отвлекающих факторов — деструкторов (Distractors) мешало работе. Когда мы находимся в таком состоянии, то мысли текут свободно, ровным потоком, ничего не отвлекает, не мешает работе, все внимание сосредоточено только над выполняемой задачей. Какие-то стандартные рутинные задачи можно выполнять в режиме многозадачности, но для эффективного выполнения интеллектуальной работы, умение войти в такой продуктивный режим критически необходимо.
После почти двадцати лет в управлении проектами, я вдруг неожиданно увидел основную проблему в новом свете. Если финальный продукт, клиентская ценность, а не внутренние процессы, совещания и бэклоги, получается только тогда, когда разработчик сможет войти в продуктивное состояние, то моя основная задача, как руководителя проекта, помочь ему максимально быстро и максимально эффективно погрузиться в написание кода. С этой точки зрения, все, что мешает сосредоточиться — деструкторы, которые нужно устранить. К числу которых относятся и плохо поставленные задачи, нечеткое распределение задач между исполнителями, постоянные согласования и обсуждения, переключения с одной задачи на другую, и многое другое, что отвлекает нас и требует нашего внимания. Секрет мастерства хорошего руководителя проектов именно в умении найти баланс, создать продуктивную атмосферу, когда с одной стороны все члены команды хорошо взаимодействуют между собой и с клиентами, а с другой стороны легко могут сосредоточиться над выполнением своей конкретной задачи.
https://cutt.ly/b2UbOXK
Комментариев нет:
Отправить комментарий