Будучи в своё время разработчиком и менеджером проектов, глава компании по разработке ПО DevSquad Фил Альвс уверен: постоянно идя на поводу у клиента и пытаясь учесть все его нужды и прихоти, можно серьёзно ограничить возможности выполнения главной задачи — качественно решить проблему заказчика. DEV.BY опубликовал три ключевых аргумента, озвученных специалистом, в пользу слова «нет».
Кем бы ни был человек, выдумавший популярную нынче фразу «клиент всегда прав», он точно не имел дела с заказчиками, у которых за грандиозными идеями не стоит ни капли технических знаний, но дай им волю — и они непременно начнут указывать, как лучше управлять разработкой.
1. Не с каждым клиентом команде будет комфортно работать
Некоторые клиенты, например, не желают вносить предоплату. В таком случае лучше предложить им отказаться от проекта, объяснив, что компания предлагает индивидуальный продукт, а не индивидуальные условия разработки. Даже если такой клиент уйдёт, команде и компании это решение будет только на руку. Проявить непреклонность в данном вопросе будет несложно, если в компании есть чётко отлаженные и проверенные процессы: подстраиваясь под каждого заказчика, она рискует затормозить своё развитие.
Это касается не только оплаты и применимо к любым аспектам работы с клиентами. Если клиент хочет работать с наиболее квалифицированными профессионалами, он должен принимать условия компании. По прогнозам Forrester, в 2018 году нанимателям придётся платить старшим разработчикам и иным востребованным специалистам до 20 процентов больше их среднего уровня зарплат. На фоне нехватки технических кадров бывает проще найти новых клиентов, чем привлечь в компанию лучших разработчиков.
Если условия сотрудничества компании неизменны и универсальны для всех заказчиков, то это не только упрощает управление проектами, но и демонстрирует сотрудникам, что их труд она ценит больше, чем жирный чек от несносного клиента. По словам Альвса, его компания может месяцами обходиться без заказов, а вот если уйдут все опытные senior-программисты — наступит настоящая катастрофа.
2. Клиент платит за качественный продукт, а не за безотказность
Многие руководители стремятся удовлетворить любую прихоть клиента из опасения потерять его или получить негативные отзывы. Но вероятность этого наоборот повышается, если команде придётся делать вещи, в которых она недостаточно компетентна, а готовый продукт не оправдает ожидания заказчика. Так, компания Альвса чётко ограничила круг предлагаемых услуг разработкой на PHP, Laravel, JavaScript, Vue.js, Node, Ionic и Electron. По его мнению, это продвинутые современные технологии, которые позволяют быстро создавать и развивать продукты.
Клиенты платят за услуги той или иной компании, потому что она может выполнить работу качественнее и быстрее, чем они смогли бы самостоятельно. Одна из проблем, с которой часто сталкивается Фил Альвс, — клиенты требуют напичкать продукт дополнительными функциями, без которых им якобы не обойтись. В таких ситуациях команде следует возразить и объяснить, что сделает продукт наиболее понятным и удобным для пользователя.
Другая частая проблема состоит в том, что клиенты не желают открывать продукт для пользователей, пока он не будет доведён до совершенства. Команда Альвса работает по проверенным agile-методам и советует клиентам отдавать продукт на испытание целевым пользователям как можно чаще и как можно раньше, чтобы начать тестирование, поиск неисправностей и доработку функционала.
3. Существует и излишнее, и недостаточно активное участие клиента в процессе
До распространения методологии гибкой разработки ПО многие компании могли тратить на выполнение проектов до трёх лет, но в итоге оказывалось, что готовый продукт не решал задачу клиента. Фил Альвс считает, что при использовании спринтов часть работающего кода вполне можно написать в течение трёх месяцев. Но чтобы работа по спринтам была эффективной, заказчик должен быть вовлечён в процесс разработки от начала и до конца.
По его мнению, постоянное общение и плотное сотрудничество — залог эффективной разработки продуктов. Старшие разработчики должны быть всегда доступны в конце каждого спринта, причём над проектами в компании Альвса они работают только парами. Согласно исследованиям, так программисты способны продумать больше вариантов решения проблемы, чем поодиночке, а, значит, создать более простой и удобный в поддержке продукт с меньшим количеством багов.
В то же время, некоторые клиенты стремятся тотально контролировать процесс, чем только отвлекают команду и тормозят завершение проекта. По этой причине имеет смысл отчитываться о проделанной работе лишь раз в конце каждого спринта, а для связи назначить аккаунт- или проект-менеджера: это позволит держать навязчивого клиента на расстоянии в ходе выполнения спринтов, но при этом добавлять критические задачи в бэклог.
Клиент обращается в компанию для того, чтобы избавиться от необходимости нанимать и контролировать независимых разработчиков. Если он хочет каким бы то ни было образом диктовать свои правила, то нет смысла обращаться к профессионалам. Поэтому — хотя заказчики не любят слышать «нет» — чтобы команда могла показать лучший результат, на который способна, компания должна уметь настоять на своём.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]