Возвращаю долг, образовавшийся в обсуждениях двух недавних заметок (#1, #2). Речь в очередной раз пойдет о том, как организуется процесс разработки ПО: должен ли процесс быть тщательно выстроенным формализованным Процессом с большой буквы "Пы" или это должна быть неформальная тусовка постоянно грызущихся между собой пауков в банке никому не подчиняющихся индивидов-"творцов".
Понятно, что все зависит от контекста. От компании. От работающих в ней людей. От задач. От технологий. От типа финансирования. От наличия и особенностей внешнего контроля. И т.д и т.п.
Очевидно, что стартап, пытающийся вывести на рынок очередную социальную сеть для безвинно пострадавших от экономического кризиса креативных ландшафтных дизайнеров, будет работать совсем в других условиях, чем компания, разрабатывающая встроенное ПО для подлежащих жесткой сертификации медицинских приборов. И что крупный аутсорсер, со штатом в 10K+ разработчиков, выживающий за счет умения привлекать толпы новых клиентов с совершенно разными проектами, будет выстраивать совсем другие процессы, чем небольшая продуктовая компания, которая зарабатывает на OpenSource инструментарии для разработчиков ПО.
Однако, есть одна общая штука, про которую кто-то может не знать вообще или же забыть под грузом повседневных забот.
Пока не сталкиваешься с управлением, можешь думать, что управление подразделением в компании или даже самой компанией -- это придумывание стратегии, поиск путей решения самых серьезных проблем, раздача производственных задач, контроль за их исполнением и т.д. Что далеко не так, на самом-то деле.
Управление -- это, как минимум, на 80% общение с людьми. Чем выше уровень руководителя, тем больше времени он уделяет общению с самыми разнообразными людьми, тем больше он занимается решением проблем этих людей, тем меньше времени у него остается на то, что со стороны представляется главными задачами управленцев: планирование, командование и контроль.
Вот так же и с процессом разработки. Непосвященным может казаться, что главное для программиста -- писать код. Для тестировщика -- гонять тесты. Для внедренца -- заниматься деплоем.
В принципе, так оно и есть. Но с одним большим "НО". Все это совершенно бесполезно без общения.
Участники проектной команды должны общаться между собой. В процессе общения происходит восприятие задачи, обмен идеями, опытом и знаниями. Формируется единое видение того, что делается, как делается, в каком состоянии находится разработка, какие проблемы есть, какие уже решены, какие находятся в процессе, какие "висят" в воздухе или отложены "на потом". Какие есть риски. Какова их тяжесть. Что можно предпринять, чтобы их минимизировать и что делать, если какой-то из рисков таки материализуется.
Более того, общение крайне необходимо для того, чтобы коллектив был здоров сам по себе, безотносительно конкретного выполняемого в данный момент проекта. Между членами коллектива должен быть налажен обмен знаниями и опытом. Люди должны уметь говорить между собой о текущих проблемах так, чтобы это не превращалось в склоки и подковерные интриги.
Убить нормальное общение очень просто. Достаточно навязать некоторый уровень формализма.
Когда член проектной команды получает очередную задачу в письменном виде и отчитывается о ее выполнении путем выставления галочки в каком-то таск-треккере. Когда в результате появления этой галочки другому члену команды приходит письмо с описанием очередной задачи и т.д., то это значит, что в организации работает отлично поставленный формализованный Процесс. С чем компанию можно поздравить. Т.к. она уверенными шагами идет по кривой дорожке минимизации производственных расходов. А придет, скорее всего, к посредственному качеству своих продуктов и увеличению тех самых производственных расходов в попытках хоть как то удерживать качество на более-менее приемлемом уровне.
Почему так? Да потому!
Причин много. Можно выбирать любую по вкусу и комбинировать их в разных сочетаниях.
Потому, что чем более формализован процесс, чем меньше непосредственного общения членов команды между собой (а зачем общение, если получение и отчет о выполнении задачи делается через инструмент вроде Project-а или JIRA), тем сильнее влияние "испорченного телефона". Анекдот о том, что занимавшийся самолечением больной умер из-за опечатки в медицинском справочнике в условиях формализованного процесса разработки вовсе не такой уже и анекдот.
Потому, что людям может быть совершенно пофиг. Сегодня есть такая задача. Ok, сделали, отправили в тестирование. Зачем сделали? Почему сделали именно сейчас? Не лучше ли было ее объединить с какой-то другой задачей? Пофиг, на самом деле. Пусть у ProjectManager-а или ProductOwner-а голова болит. А разработчику уже следующая задача в почтовый ящик упала. Так то думать некогда, трясти надо.
Потому, что чем больше людей в проектной команде, чем хуже они "сыграны" как команда, тем больше издержек на передачу информации между ними. Тем более, если передача информации осуществляется только через почту/Project/SharePoint/Wiki или еще что-то подобное.
Таким образом, если отказаться от формализованной раздачи заданий, плотно завязать общение членов команды исключительно на очное и личное общение, да при этом уменьшить размер проектной команды, то можно избавиться от значительной доли накладных расходов, которые налагает формализованный процесс.
Но что значит уменьшать размер проектных команд? Ведь объемы работы имеют свойства увеличиваться, а не уменьшаться. Как быть?
Тут нужно помнить про пару важных вещей. Во-первых, производительность у разных сотрудников может различаться очень сильно. ДеМарко и Листер, например, говорят о 10-кратной разнице между самыми лучшими и самыми худшими. Сам я пока такую разницу в производительности не видел, но менее существенные разрывы наблюдать приходилось. Так что первое, чем нужно озадачится -- это подбором правильных людей. И заботой о них (для чего, опять же, нужно общение).
Во-вторых, большим вовлечением каждого члена команды в задачи других членов команды. Чем больше твой кругозор, чем больше ты знаешь о проблемах коллег, тем проще тебе будет принимать решения, способствующие решению не только твоей персональной задачи, но и задач тех, кто с тобой связан.
Ну вот совсем тупые примеры. Разработчик пишет DLL-ку, которая будет использоваться другими членами команды (как разработчиками, так и тестировщиками). DLL-ка экспортирует всего несколько публичных функций/классов, но для того, чтобы тщательно протестировать ее реализацию, этого недостаточно. Может ли автор DLL-ки упростить жизнь тестировщикам? Может. Все главные потроха DLL можно формить в виде обычной статической библиотеки, которая задействуется внутри DLL. Т.к. библиотека статическая, все ее содержимое доступно и ее можно покрывать какими угодно тестами.
Или внедренцу нужно готовить тестовые стенды, на которых тестировщики затем будут гонять интеграционные тесты. А процесс развертывания компонента оказывается слишком неудобным из-за особенностей конфигурирования приложения. Или невнятных сообщениях об ошибках в конфугурации. Или же логирование в приложении настолько неудачное, что ни внедренец, ни тестировщик не могут вовремя понять, что приложение толком не стартовало и подключение к какому-то внешнему ресурсу не было выполнено. Когда разработчик тесно общается с внедренцем/тестировщиком, он быстро узнает о чужих проблемах и оперативно устраняет их не дожидаясь пинка он менеджера. А если разработчик сам побудет немного в шкуре внедренца, то быстро научится относиться к run-time диагностике как положено, а не спустя рукава.
Или дизайнер расположил на форме мобильного приложения красочный анимированный элемент, который должен менять степень своей прозрачности пока приложение проверят криптографическую подпись полученных от сервера данных. Но вся эта красота умудряется тормозить даже на топовых моделях телефонов, не говоря уже про прошлогодние модели, которые будут у 80% пользователей приложения. Если дизайнер и разработчик плотно общаются друг с другом, то дизайнер может вовремя понять, что анимация с изменением прозрачности это круто в прототипах, но не практично в реальности. А разработчик может вовремя узнать, что фишка с анимацией -- это тот самый крючок, на который удалось подцепить VIP-клиента и что было обещано самому-самому главному боссу-заказчику. И поэтому нужно напрячься больше обычного и что-то придумать: либо провести оптимизацию, либо научиться демонстрировать анимацию только на достаточно мощных для этого телефонах.
Ни одна из описанных ситуаций не является проблемой в небольшой, неформальной, плотно общающейся продуктовой команде. Но каждая из них будет увеличивать накладные расходы при наличии формального Процесса, в котором каждый участник привык делать только то, что ему предписано, а со всем остальным пусть разбираются где-нибудь наверху.
Возможно, сказывается мой специфический профессиональный опыт, который был связан именно с небольшими проектными командами, в буквальном смысле живущими выпуском продукта. Но именно этот опыт убедительно доказывает, что такой подход действительно работает. Проверено на людях :)
Значит ли это, что такой процесс легко организовать? Вовсе нет. Совсем даже наоборот.
Например, потому, что этот подход чрезвычайно сильно зависит от правильно подобранных друг к другу правильных людей. Кто пытался собирать и растить команды, тот знает, насколько все это непросто.
Например, потому, что зависимость от случайностей и форс-мажоров в маленькой команде гораздо выше. Сломал один из сотрудников ногу, а второй ушел с горя в запой, третий вынужден сидеть с маленькими детьми, пока его супруг(а) в командировке... И?
Тем не менее, этот подход работает. И я бы даже больше сказал: если у вас есть задача выпустить продукт быстро и с высоким качеством, то других работающих альтернатив нет. Ну а форсмажоры могут убить вообще все что угодно. В конце-концов, все мы смертны и любого из нас на улице может зашибить насмерть какой-нибудь пьяный водитель.
Почему же, если этот подход работает, все время наблюдаются попытки отказаться от него в пользу формального Процесса?
Причин множество.
Ну вот, например, что нужно для управления небольшой проектной командой, перед которой поставлен задача выпуска продукта?
Как минимум, нужен руководитель, который будет обладать: a) четким пониманием что делается и зачем это делается, b) умением наблюдать и анализировать происходящее, делать выводы, c) здравым смыслом и, крайне желательно, жизненным опытом, d) волей и полномочиями.
Мне одному кажется, что такое сочетание качеств -- это уже довольно редкое явление? Особенно подозрительно в этом списке выглядит пункт про полномочия. Мало кто из руководителей готов раздавать широкие полномочия своим подчиненным. Например, потому, что крайне неприятно отвечать за чужие проколы. А еще потому, что ты сам можешь не иметь достаточных полномочий, т.к. те, кто над тобой, тоже не хотят отвечать за твои проколы.
Что еще нужно? Нужны люди, те самые члены проектной команды, которые готовы жить проектом. И которые готовы ставить свое будущее в зависимость от субъективного мнения руководителя проекта. Ведь это довольно стремно, когда твоя зарплата и твое повышение зависят от того, нравишься ли ты тим-лиду/проджект-менеджеру или ты с ним разругался в пух и прах. Совсем другое дело, когда рост зарплаты и должности обусловлен формальными показателями -- сколько тасков в неделю закрывается, какой процент багов переоткрывается, насколько расходятся предсказания времени выполнения тасков с фактически залогированным временем и т.д., и т.п.
Но все это меркнет по сравнению с тем, какую религию исповедует ТОП-менеджмент. Если для ТОПов идеальной картинкой производства является швейная фабрика, конвейер по сборке автомобилей или даже конструкторское бюро времен Второй Мировой, когда скорость разработки проекта определялась количеством кульманов на которых одновременно создавались проектные чертежи... То во главу угла будет поставлен тотальный учет и контроль под высоко поднятым знаменем снижения издержек.
В итоге будет выстроен процесс, который "по щелчку" позволяет поднять информацию о том, чем абстрактный Вася Пупкин занимался, скажем, 12 июня 2014-го года. Восемь часов крутил гайку №6 ключом на 12 для проекта X? Отлично. Налицо 100% утилизация ресурса "Вася Пупкин" на конкретном временном отрезке. Заодно очевидно, из чего складывались расходы по проекту X.
То, что эту гайку вообще не нужно было бы крутить, если бы за пару дней до этого Федя Иванов смог в течении пятнадцати минут переговорить с Ваней Федоровым и понять, как решить проблему уже имеющимися средствами, то это уже никому не интересная частность. Работа проделана, в отчетах и табелях зафиксирована, деньги получены и проедены. Кому, собственно, какое дело? Тем более, если часть менеджеров, отвечавших за тот проект, уже благополучно ушла на повышение в другую компанию...
PS. Повторюсь, проблема противопоставления слабоформализованной проектной команды тщательно разработанному формальному Процессу намного шире, чем можно освятить в небольшой заметке. Желающих более детально разобраться в проблеме отсылаю к замечательным книгам ДеМарко и Листера (минимум "Человеческий фактор" и "Deadline. Роман об управлении проектами"). А так же Генри Минцберга. В частности, в его книге "Структура в кулаке" очень хорошо описано чем адхократии (т.е. гибкие проектные команды) отличаются от механистических бюрократий (т.е. формальные Процессы). Насколько все это применимо к вашим рабочим условиям, насколько вы можете повлиять на эти условия, хватит ли у вас смелости, воли, характера и здравого смысла оказать такое влияние -- это уже совсем отдельный вопрос. И вряд ли этот вопрос ко мне :)
PPS. Вот здесь есть выжимки о процессе разработки и его улучшении из книги Тома ДеМарко "Deadline. Роман об управлении проектами".
Комментариев нет:
Отправить комментарий