Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - Джефф Лоусон

случае с Озоном. Когда разработчики действительно увлечены работой, включается внутренняя мотивация, которая помогает генерировать новые и еще более творческие идеи. Когда они просто изучают техническое задание, у них нет ощущения связи с теми, кто будет использовать ПО. Код становится громоздким и подверженным ошибкам из-за незнания того, как он будет использоваться. Плюс и сам процесс написания кода занимает целую вечность, поскольку разработчик не увлечен им, а его интуиция спит.

Вот почему, если вы когда-нибудь соприкасались с разработчиками или у вас были команды, создающие ПО для вашего бизнеса, вам приходилось прилагать массу усилий, чтобы ускорить процесс. Но он, похоже, всегда занимает больше времени, чем хотелось бы. Чад Этцель, он же Джаззи Чад, считает это естественным следствием неправильного процесса, в котором менеджеры указывают разработчикам, какие именно решения создавать, а не включают их в процесс на более раннем этапе, когда проблема, подлежащая решению, только еще определяется.

«Руководство компании требует от менеджеров достижения деловых или финансовых целей. Поэтому менеджеры придумывают идею продукта и устанавливают сроки, но они зависят от разработчиков, выполняющих задания. Технической команде тяжело, если кто-то просто приходит и говорит: “Сделай это быстро и к такому-то сроку”, а затем убегает».

Включение разработчиков в процесс обсуждения задания на раннем этапе – это не просто вопрос вежливости и стремление не обидеть. Подобный подход дает реальные преимущества. Как менеджеры могут выдерживать сроки, если они не понимают сути реальной работы, подлежащей выполнению? Что делать, если проблему невозможно решить в установленные сроки? Либо будет урезана функциональность, либо работа будет выполняться в спешке, либо разработчики перегорят и уйдут в другое место. Это нельзя назвать хорошим результатом.

Вместо того чтобы предлагать инженерам какое-то решение, менеджеры по продукту могут поделиться проблемой и попросить их помочь найти самый быстрый способ решения с учетом существующих систем.

«Каждый раз, когда я слышу фразы вроде “Это должно быть сделано быстро” или “Вы можете сделать это за день”, они сводят меня с ума, – говорит Чад. – Дело в том, что, пока не поймешь, как увязать все это, как построена инфраструктура, невозможно представить, сколько времени уйдет на работу. Думаю, что именно из-за этого порою и возникают разногласия между менеджерами и инженерами».

Чад отмечает, что многие разработчики «более глубоко понимают возможности интеграции или технической приемлемости некоторых продуктов либо функций, когда менеджер продукта говорит: “Нам нужна такая-то и такая-то функция”, а инженер отвечает: “Отлично, это займет шесть месяцев, поскольку при данной организации инфраструктуры мы не можем просто добавить эту функцию”. Но тогда менеджер может не до конца понимать, почему это так трудно».

Поиск самого простого технического решения либо кратчайшего пути в конкретной обстановке – это именно то, чем инженеры зарабатывают на жизнь. Это именно то, чему их учат. На самом деле существует так называемый алгоритм Дейкстры, который находит кратчайший путь между несколькими узлами, и все мы хорошо знаем его. Но вместо того чтобы использовать эту возможность, большинство компаний советуют разработчикам забыть о ней. Это почти преступление.

Джаззи Чад настолько талантливый разработчик, что я до сих пор сожалею о нашей неспособности найти достойное применение его творческого воображения, пока он работал в компании Twilio. Он пришелся ко двору в компании Apple, где уже более четырех лет занимается iOS – операционной системой iPhone и iPad.

Чем они его привлекли? Предложением решать проблемы и свободы поиска. Когда он присоединился к Apple, руководство определило Чада в команду специалистов по искусственному интеллекту, где не было разработчиков мобильных приложений его уровня. Затем перед ним поставили задачу: выяснить, как лучше всего заставить помощника Siri делать нечто больше, чем просто голосовое управление. Это Чад разработал все «рекомендации Siri» в вашем iPhone. Чад любит свободу. Вместо того чтобы сказать ему «Этот пиксель идет сюда», его менеджер просто говорит: «Подумай, что ценного Siri может дать клиентам iPhone».

Среди прочего Чад подчеркивает, что менеджеры могут подключать разработчиков к удовлетворению потребностей клиентов и помогать им принимать решение. Высокопрофессиональные менеджеры по продукту – это не промежуточные звенья между потребностями клиентов и разработчиками. На самом деле они устраняют все лишнее – предвзятые решения и ошибочные предположения – и упрощают коммуникацию. Высокопрофессиональные менеджеры по продукту не изолируют разработчика от потребностей клиента – они облегчают ему понимание проблем клиента. Чем больше лишних звеньев между клиентами и разработчиками, тем хуже. Это игра в испорченный телефон, где сообщение передается через такое количество людей, что у разработчиков почти не остается шансов понять клиентов, использующих созданное ими ПО.

Почему существует плохое программное обеспечение

Один из экстремальных примеров проблемы «слишком большого числа промежуточных звеньев» приводит Патрик Маккензи (он же Patio11), который работал на японского системного интегратора, предоставляющего аутсорсинговые услуги по разработке ПО японским компаниям, в основном учебным заведениям. Бизнес-модель этой компании переводила проблему «совместного поиска решений» почти на астрономический уровень. В одном особенно неудачном проекте длинная цепочка промежуточных звеньев так достала Патрика, что он ушел не только из фирмы, но и из мира бизнеса на более чем 15 лет.

Один из японских университетов решил автоматизировать ручную систему выставления счетов. В ручном режиме работник сидел за столом с кипой счетов-фактур с левой стороны стола и стопкой банковских выписок – с правой. Он вписывал необходимую информацию в счета-фактуры и ставил печать на тех, что подлежали оплате. Естественно, университет хотел получить программу для выполнения этой операции. Таким образом, администратор в университете направил запрос университетскому закупщику, контактировавшему с представителем фирмы, тот передал техническое задание менеджеру проекта, который переадресовал его менеджеру по продукту, а последний – инженерам.

Задание было таким: разработать компьютерную программу, которая воспроизводит виртуальную стопку счетов-фактур в левой части экрана и виртуальную стопку банковских выписок – в правой. Оператор кликает элемент в левой стопке, затем соответствующий элемент в правой стопке и под конец нажимает клавишу «Enter». Это была в буквальном смысле имитация ручного процесса, но на экране компьютера.

«Наши представители по работе с заказчиками сказали: “Да, мы можем создать такую программу”, а когда это задание дошло до разработчиков, мы