Мне постоянно попадаются статьи, в которых разработчиков упрекают за нежелание вникать, зачем нужна их работа, и доказывают им, что это неправильно – вслепую вносить изменения, не разбираясь, какая за этим стоит цель. Звучат призывы в духе «оглянитесь вокруг, не уходите с головой в написание кода!». На мой взгляд, эти статьи обращены не к тем людям.
В большинстве компаний ответственность за то, что разработчики оказываются отрезаны от пользователей и их нужд, лежит на руководстве. Если кто не знал: разработчики ничего не имеют против того, чтобы создавать крутые программные решения под реальные потребности, и наоборот, перспектива тратить время на то, что никому не нужно, как минимум не вызывает у них энтузиазма, а то и действует на нервы. Ну то есть, процесс написания программ разработчикам и сам по себе нравится, поэтому пока можно получать деньги за код и никаких более привлекательных вариантов не наблюдается, они будут продолжать работать. Однако как только представится возможность заняться чем-то более осмысленным с сохранением оплаты, машины на автопилоте делать, допустим, или инсулиновую помпу закрытого цикла, – только вы их и видели.
Проблема, которая не позволяет разработчикам делать продукты, закрывающие реальные потребности, кроется в менеджменте – ее истоки можно проследить вплоть до высших корпоративных эшелонов. Дело в том, что пользовательские потребности выявляются на протяжении всего жизненного цикла процесса, и их выявление неизбежно влечет за собой пересмотр изначально заявленных масштабов работы.
Организации, живущие по заветам университетских программ делового администрирования, избегают моделей с нефиксированными объемами работ. Им проще сосредоточиться на том, чтобы у технических команд было что-нибудь Готово к определенному сроку. Готово обычно бывает что-то никому не нужное, потому что вопрос об определении реальных потребностей аудитории замяли. Вдобавок в проекте обычно царит полный хаос, потому что команда раз за разом бросает силы на то, чтобы делать новый функционал, вместо того чтобы оценить свою работу и устранить тот самый хаос. Единственный плюс того, что проект довели до состояния Готово — как правило, это событие отмечают пиццей и тортом. Если очень повезет, то еще и умеренным повышением кого-нибудь из команды, за то, что уложились в сроки. Правда, в реальности новым функционалом люди не пользуются, но это до поры до времени не имеет значения, пока в один прекрасный день кто-нибудь (как правило, финансовый директор) не посчитает KPI по формуле 4Х и не урежет команде финансирование.
Для сложившейся ситуации в разработке ПО можно привести историческую параллель. Где-то в сороковых годах прошлого века Уильям Эдвардс Деминг предложил производителям автомобилей Детройта новую методику автомобилестроения. В Детройте в то время деньги гребли лопатой за счёт того, что успели захватить самый прибыльный рынок в мире, и, честно сказать, не видели смысла что-то менять в принципе. Получив отказ, Деминг перешел на другие виды деятельности, стал принимать участие в восстановлении японской экономики после войны. Там его методы показали себя хорошо, и понемногу машины японского производства стали теснить Детройт на рынке.
Форд получил наглядный урок, когда столкнулся с тем, что покупатели были готовы ждать и доплачивать, лишь бы купить машину марки Форд с коробкой передач производства компании Тойота. Инженеры компании в недоумении разобрали коробки, чтобы сравнить детали, и по замерам выяснили, что у продукции Тойота детали в два раза точнее соответствуют чертежам. Благодаря этому в механизмах всё стыковалось лучше и давало меньше перебоев в работе.
К 1981 году, когда Япония подтачивала позиции Форда на рынке уже десятки лет, руководство наконец сдалось и пригласило Деминга отладить производство. В их преставлении проблема заключалась в качестве изготовления деталей – иными словами, в рабочих, которые изготавливали недостаточно качественные детали. Ведь не начальство же этим занимается. К большому их удивлению, Деминг заявил, что 85% проблем, негативно влияющих на качество продукции, происходят от неправильного руководства. Компании понадобилось шесть лет, чтобы перейти на новую модель, и результатом стала линейка автомобилей Taurus-Sable – на голову выше того, что они делали до этого.
Основной ошибкой компании Форда было то, что, продумывая, как можно улучшить производство, руководство не обращалось к людям, которые занимались им непосредственно. Компании удалось значительно поднять качество продукции простым способом: менеджерам было поручено опросить рабочих на тему того, что и как можно делать лучше. Замечания выслушивались, а затем на их базе в процесс производства вводились новые практические усовершенствования. Раньше они использовали другой подход – менеджеры сами придумывали абстрактные усовершенствования (зачастую с подачи начальства) и заставляли рабочих их внедрять. Сегодня мы наблюдаем тот же антипаттерн оптимизации сверху вниз в разработке ПО.
Теперь вернемся к тем статьям с призывами «разработчики, подтянитесь!», которыми кишит Интернет. Давайте представим, что они обращены к рабочим, занятым в автомобилестроительстве. Прямо вижу эти заголовки:
Авторы хотят как лучше и, на первый взгляд, вроде бы дают разумные советы. Но как именно эти самые работники автомобильной промышленности должны перекраивать рабочие процессы? Им предлагается переучивать начальство? В истории прецедентов особо не встречается, и я сильно сомневаюсь, что и сейчас это кому-то удастся. В подобной же ситуации оказываются и разработчики многих компаний. Большинство работает под игом выпускников по специализации делового администрирования. Каждый разработчик становится метафорическом винтиком в системе PMP/WBS – всем по диаграмме Ганта, менеджеру проекта и индикатору типа задачи.
И даже когда компания, работающая по традиционной модели, решает переключиться на Agile, зачастую всё выливается во внедрение антипаттерна Date Scrum, который прекрасно уживается со стандартным подходом к руководству. Растущая популярность Date Scrum привела к тому, что у многих разработчиков сложилось неприязненное отношения к практикам Agile вообще. Их сложно винить: если до внедрения Agile им приходилось терпеть собрания с отчетом по текущим задачам раз в пару недель, то с Date Scrum приходится страдать ежедневно!
Поэтому нам нужно больше статей, которые призывали бы высшее руководство, да и всю цепочку менеджмента в целом, прекратить саботировать проекты по разработке ПО. Статьи, которые указывали бы на то, что управленцы, работающие традиционной схеме, со своими подробными оценками сроков и прочими техниками, рассчитанными на оптимизацию производства, выполнения заказов и логистики, вторгаются на территорию, где всему этому не место. Да, техники хорошие, мы с ними войну выиграли и, если я когда-нибудь открою фабрику, обязательно буду их использовать. Но в проектах по разработке ПО им делать нечего.
Так почему многие проекты в IT оканчиваются крахом? Разработка намного больше напоминает создание новой фабрики, чем подержание деятельности на уже существующей. Традиционный менеджмент рассчитан как раз на последнее – он применяет жёсткие, отработанные практики для организации задач, время выполнения которых известно заранее. Разработка складывается из последовательности множества задач, время выполнения которых неизвестно. Из-за этой заложенной в самой природе деятельности непредсказуемости традиционные техники, в которых планирование основано на прогнозах, абсолютно к ней не подходят.
Форду понадобилось сорок лет, чтобы перенять модель, разработанную Демингом. Сейчас темп жизни ускорился, и компании, которые ещё сорок лет намерены продолжать дёргать талантливых разработчиков, просто не вытянут. Полагаю, что большая часть тех, кто будет сопротивляться изменениям, пойдет ко дну уже лет через десять. Подобные мрачные предзнаменования вызваны тем, что компании с традиционным подходом работают по методичкам, написанным для промышленной сферы. Они разбивают сотрудников на группы по типу работ, а затем оптимизируют все отделы при помощи одного набора жёстких, шаблонных «лучших практик», которые обычно один в один списаны с фабричных. Именно это препятствует созданию продуктов, которые несли бы ценность за счёт выявления и закрытия важных потребностей, и приводит к тому, что разработчики вынуждены с головой уходить в код, который в конечном счёте никому не нужен. По той же причине в компаниях упорно закрывают глаза на все знаки того, что проект сошел с рельсов – в них слишком крепко прижились застарелые антипаттерны из университетских программ. Например:
Итак, с разработчиками всё в порядке, а вот руководству с традиционными методами необходимо меняться. Начать можно с того, что прислушаться к тем рекомендациям по организации работы, которые дают сами разработчики:
Следует обратить внимание и на то, чего разработчики просят не делать:
Учитывая мнение разработчиков, руководство должно отказаться от следующих практик, которые плохо приспособлены для проектов, связанных с ПО:
В команде iiSM.ORG бытует мнение, что ПО меняет в жизни, работе и развлечениях людей очень многое за счет оптимизации и автоматизации. Доля IT-предприятий среди мировых топ-компаний неуклонно растёт по экспоненте, и вскоре наш ждёт целый поток изменений, который вызовет переворот в бизнесе и видоизменит общество. Если мы правы (а я полагаю, что правы), то руководителям, работающим по старинке, придётся подстраиваться под реалии мира после цифровой трансформации. Поэтому давайте не пожалеем времени на то, чтобы донести: традиционные техники менеджмента попросту не работают применительно к разработке ПО и продержаться на них в долгосрочной перспективе невозможно.
В большинстве компаний ответственность за то, что разработчики оказываются отрезаны от пользователей и их нужд, лежит на руководстве. Если кто не знал: разработчики ничего не имеют против того, чтобы создавать крутые программные решения под реальные потребности, и наоборот, перспектива тратить время на то, что никому не нужно, как минимум не вызывает у них энтузиазма, а то и действует на нервы. Ну то есть, процесс написания программ разработчикам и сам по себе нравится, поэтому пока можно получать деньги за код и никаких более привлекательных вариантов не наблюдается, они будут продолжать работать. Однако как только представится возможность заняться чем-то более осмысленным с сохранением оплаты, машины на автопилоте делать, допустим, или инсулиновую помпу закрытого цикла, – только вы их и видели.
Проблема, которая не позволяет разработчикам делать продукты, закрывающие реальные потребности, кроется в менеджменте – ее истоки можно проследить вплоть до высших корпоративных эшелонов. Дело в том, что пользовательские потребности выявляются на протяжении всего жизненного цикла процесса, и их выявление неизбежно влечет за собой пересмотр изначально заявленных масштабов работы.
Организации, живущие по заветам университетских программ делового администрирования, избегают моделей с нефиксированными объемами работ. Им проще сосредоточиться на том, чтобы у технических команд было что-нибудь Готово к определенному сроку. Готово обычно бывает что-то никому не нужное, потому что вопрос об определении реальных потребностей аудитории замяли. Вдобавок в проекте обычно царит полный хаос, потому что команда раз за разом бросает силы на то, чтобы делать новый функционал, вместо того чтобы оценить свою работу и устранить тот самый хаос. Единственный плюс того, что проект довели до состояния Готово — как правило, это событие отмечают пиццей и тортом. Если очень повезет, то еще и умеренным повышением кого-нибудь из команды, за то, что уложились в сроки. Правда, в реальности новым функционалом люди не пользуются, но это до поры до времени не имеет значения, пока в один прекрасный день кто-нибудь (как правило, финансовый директор) не посчитает KPI по формуле 4Х и не урежет команде финансирование.
В истории уже такое было
Для сложившейся ситуации в разработке ПО можно привести историческую параллель. Где-то в сороковых годах прошлого века Уильям Эдвардс Деминг предложил производителям автомобилей Детройта новую методику автомобилестроения. В Детройте в то время деньги гребли лопатой за счёт того, что успели захватить самый прибыльный рынок в мире, и, честно сказать, не видели смысла что-то менять в принципе. Получив отказ, Деминг перешел на другие виды деятельности, стал принимать участие в восстановлении японской экономики после войны. Там его методы показали себя хорошо, и понемногу машины японского производства стали теснить Детройт на рынке.
Форд получил наглядный урок, когда столкнулся с тем, что покупатели были готовы ждать и доплачивать, лишь бы купить машину марки Форд с коробкой передач производства компании Тойота. Инженеры компании в недоумении разобрали коробки, чтобы сравнить детали, и по замерам выяснили, что у продукции Тойота детали в два раза точнее соответствуют чертежам. Благодаря этому в механизмах всё стыковалось лучше и давало меньше перебоев в работе.
К 1981 году, когда Япония подтачивала позиции Форда на рынке уже десятки лет, руководство наконец сдалось и пригласило Деминга отладить производство. В их преставлении проблема заключалась в качестве изготовления деталей – иными словами, в рабочих, которые изготавливали недостаточно качественные детали. Ведь не начальство же этим занимается. К большому их удивлению, Деминг заявил, что 85% проблем, негативно влияющих на качество продукции, происходят от неправильного руководства. Компании понадобилось шесть лет, чтобы перейти на новую модель, и результатом стала линейка автомобилей Taurus-Sable – на голову выше того, что они делали до этого.
Основной ошибкой компании Форда было то, что, продумывая, как можно улучшить производство, руководство не обращалось к людям, которые занимались им непосредственно. Компании удалось значительно поднять качество продукции простым способом: менеджерам было поручено опросить рабочих на тему того, что и как можно делать лучше. Замечания выслушивались, а затем на их базе в процесс производства вводились новые практические усовершенствования. Раньше они использовали другой подход – менеджеры сами придумывали абстрактные усовершенствования (зачастую с подачи начальства) и заставляли рабочих их внедрять. Сегодня мы наблюдаем тот же антипаттерн оптимизации сверху вниз в разработке ПО.
Теперь вернемся к тем статьям с призывами «разработчики, подтянитесь!», которыми кишит Интернет. Давайте представим, что они обращены к рабочим, занятым в автомобилестроительстве. Прямо вижу эти заголовки:
Американским рабочим нужно всерьёз задуматься надо отладкой производственных процессов – перенимайте опыт компании Тойота!
Рабочим следует итерировать совместно с клиентами, чтобы создавать автомобили наивысшего качества.
Рабочие на производстве автомобилей слишком много внимания уделяют деталям в ущерб пониманию причин.
Создание хорошего автомобиля не сводится к изготовлению и сборке деталей.
Авторы хотят как лучше и, на первый взгляд, вроде бы дают разумные советы. Но как именно эти самые работники автомобильной промышленности должны перекраивать рабочие процессы? Им предлагается переучивать начальство? В истории прецедентов особо не встречается, и я сильно сомневаюсь, что и сейчас это кому-то удастся. В подобной же ситуации оказываются и разработчики многих компаний. Большинство работает под игом выпускников по специализации делового администрирования. Каждый разработчик становится метафорическом винтиком в системе PMP/WBS – всем по диаграмме Ганта, менеджеру проекта и индикатору типа задачи.
И даже когда компания, работающая по традиционной модели, решает переключиться на Agile, зачастую всё выливается во внедрение антипаттерна Date Scrum, который прекрасно уживается со стандартным подходом к руководству. Растущая популярность Date Scrum привела к тому, что у многих разработчиков сложилось неприязненное отношения к практикам Agile вообще. Их сложно винить: если до внедрения Agile им приходилось терпеть собрания с отчетом по текущим задачам раз в пару недель, то с Date Scrum приходится страдать ежедневно!
Что такое Date Scrum?
Это практика из сферы R&D, которая предписывает разработчикам оценивать проектные требования сразу для всей протяженности работ целиком. Когда проекту дают зелёный свет и утверждают бюджет на базе конечных оценок, команда каждый день собирается на встречах (скрамах), чтобы отчитаться по текущему положению и нейтрализовать рискованные моменты; таким образом решение «итерируется» по мере продвижения к дате релиза. Некоторые воспринимают этот подход как каскадную модель, только реализованную спринтами.
Поэтому нам нужно больше статей, которые призывали бы высшее руководство, да и всю цепочку менеджмента в целом, прекратить саботировать проекты по разработке ПО. Статьи, которые указывали бы на то, что управленцы, работающие традиционной схеме, со своими подробными оценками сроков и прочими техниками, рассчитанными на оптимизацию производства, выполнения заказов и логистики, вторгаются на территорию, где всему этому не место. Да, техники хорошие, мы с ними войну выиграли и, если я когда-нибудь открою фабрику, обязательно буду их использовать. Но в проектах по разработке ПО им делать нечего.
Так почему многие проекты в IT оканчиваются крахом? Разработка намного больше напоминает создание новой фабрики, чем подержание деятельности на уже существующей. Традиционный менеджмент рассчитан как раз на последнее – он применяет жёсткие, отработанные практики для организации задач, время выполнения которых известно заранее. Разработка складывается из последовательности множества задач, время выполнения которых неизвестно. Из-за этой заложенной в самой природе деятельности непредсказуемости традиционные техники, в которых планирование основано на прогнозах, абсолютно к ней не подходят.
Форду понадобилось сорок лет, чтобы перенять модель, разработанную Демингом. Сейчас темп жизни ускорился, и компании, которые ещё сорок лет намерены продолжать дёргать талантливых разработчиков, просто не вытянут. Полагаю, что большая часть тех, кто будет сопротивляться изменениям, пойдет ко дну уже лет через десять. Подобные мрачные предзнаменования вызваны тем, что компании с традиционным подходом работают по методичкам, написанным для промышленной сферы. Они разбивают сотрудников на группы по типу работ, а затем оптимизируют все отделы при помощи одного набора жёстких, шаблонных «лучших практик», которые обычно один в один списаны с фабричных. Именно это препятствует созданию продуктов, которые несли бы ценность за счёт выявления и закрытия важных потребностей, и приводит к тому, что разработчики вынуждены с головой уходить в код, который в конечном счёте никому не нужен. По той же причине в компаниях упорно закрывают глаза на все знаки того, что проект сошел с рельсов – в них слишком крепко прижились застарелые антипаттерны из университетских программ. Например:
- Разработчики, которые тратят вполне разумное количество дополнительного времени на то, чтобы проверить то, что сделано, и устранить хаос, считаются «какими-то неспешными».
- Разработчиков, которые замечают какое-либо несоответствие между продуктом и запросами рынка, мягко отправляют обратно за клавиатуру, строгать новый функционал. Всё, на что они могут рассчитывать – обещание, что группа, генерирующая идеи, обо всём позаботится.
- Разработчики, которые быстро выкатывают продукты на суд соответствующей сторонней группы, ценятся, потому что оперативно приводят всё в состояние Готово.
- Разработчиков, которые ведут полевые наблюдения и видят, что пользователи испытывают трудности с продуктом, ненавязчиво возвращают в рамки общей программы.
- Техлидов, которые пытаются вникнуть в Общую Картину (как продукт приспособлен к рынку, как определяются цены и состав пакетов услуг), похлопывают по плечу и отправляют обратно, мотивировать разработчиков на производство очередного функционала сомнительной полезности.
- Разработчикам, которые пытаются держать ситуацию под контролем при помощи техник статистического управления хаосом, рекомендуют оставить всё это группе, ответственной за Качество – как будто люди, которые не писали код, справятся с делом лучше!
Итак, с разработчиками всё в порядке, а вот руководству с традиционными методами необходимо меняться. Начать можно с того, что прислушаться к тем рекомендациям по организации работы, которые дают сами разработчики:
- Ясно излагать людям назначение их работы, видение, миссию;
- Не жалеть ресурсов на развитие работников, давать им возможность двигаться вперед;
- Предоставлять автономию, делегировать полномочия.
Следует обратить внимание и на то, чего разработчики просят не делать:
- Избегать контроля в мелочах: код всё-таки пишут разработчики, не менеджеры;
- Не приходить в команду с нулём технических знаний: нет ничего хуже, чем руководитель, который смотрит мутным взглядом, когда пытаешься ответить на его вопрос.
- Не прогибаться под любым давлением: корпоративная политика однозначно входит в сферу ответственности менеджера. Пожалуйста, представляйте интересы команды на совесть.
Учитывая мнение разработчиков, руководство должно отказаться от следующих практик, которые плохо приспособлены для проектов, связанных с ПО:
- Планирование по прогнозам, которое строится на дробной оценке сроков. Это годится для процессов, в которых точно известно время исполнения задач, разработка к ним не относится.
- Дробная оценка сроков силами разработчиков.
- Иерархическая структура работ – опять же, хороша там, где точно известно время исполнения.
- Определение дью исходя из некорректных оценок сроков.
- Применение Agile Scrum, за исключением случаев, когда работа ведётся в связке с заказчиком, который в этом разбирается.
- Некритическое принятие масштабов проекта, заявленных группой, которая генерирует идеи.
Что за группы, генерирующие идеи?
Это структуры внутри компании, которым поручается придумывать новые продукты и новый функционал. Затем их идеи передаются на реализацию другой группе. Во многих компаниях за этот круг задач отвечают менеджеры продуктов.
В команде iiSM.ORG бытует мнение, что ПО меняет в жизни, работе и развлечениях людей очень многое за счет оптимизации и автоматизации. Доля IT-предприятий среди мировых топ-компаний неуклонно растёт по экспоненте, и вскоре наш ждёт целый поток изменений, который вызовет переворот в бизнесе и видоизменит общество. Если мы правы (а я полагаю, что правы), то руководителям, работающим по старинке, придётся подстраиваться под реалии мира после цифровой трансформации. Поэтому давайте не пожалеем времени на то, чтобы донести: традиционные техники менеджмента попросту не работают применительно к разработке ПО и продержаться на них в долгосрочной перспективе невозможно.
