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