Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - [39]

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

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

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

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

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

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

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

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

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

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

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

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