Добавить свою заметку вы можете на этой странице.
5 принципов постановки задач
Хотел бы обсудить с читателями один интересный процесс: постановку задач.
Мы много работаем с клиентами, и даже самые адекватные из них пишут порой что-то несусветное. Особенно, это заметно на крупных проектах, когда сначала все хорошо, все счастливы, клиент тратит время на наши вопросы и грамотно ставит задачи. Но уже после середины проекта, клиент устает и начинает думать, что мы уже в теме, уже разбираемся в его бизнесе, процессах, а значит и в том, какой функционал дальше делать. Более того, во большинстве проектов это действительно так, но по очень многим аспектам такие ожидания расходятся: у клиента одно видение, у команды разработчиков другое, а у менеджера проекта что-то посередине.
Эффективная и выгодная реклама с сервисом от МегаФона
Широкий выбор рекламных каналов, более 100 параметров по интересам, подробная аналитика и другие возможности уже ждут в Личном кабинете. А еще кешбэк 100% за запуск рекламы в первый месяц и еще 10% — каждый месяц.
Пример: клиент попросил добавить простую галерею фото на одной из страничек. Как это видит клиент: галерея представляет собой картинку, справа и слева от нее находятся стрелки. Под основной картинкой располагаются картинки поменьше (на них идет переключение при нажатии стрелки вправо), примерно 4-5 штук. Смену можно делать не только стрелкой, но и свайпом на мобильный устройствах, равно как и свайпом мышки. При нажатии на основную картинку открывается попап с ее увеличенным и вписанным по высоте или ширине экрана размером. Смена в попапе происходит по тому же принципу. И все это дело еще нужно зациклить в карусели.
Но задача от клиента звучит так: "Сделайте галерею фото, чтобы можно было их листать. Стрелки там, ну вы поняли. А если нажать на фото то оно увеличиваться должно"
Как это видит менеджер: "Окей, галерея фото. Ага, мы делали классную галерею на проекте для ресторана "Твой хавчик", возьмем оттуда. В нее входит даже больше возможностей, чем описал мистер Василий"
Каков итог? Разработчик прикрутит эту супер-галерею, а заказчик останется недоволен. По сути, постановка задачи - это крайне важный момент, касающейся ответственности. Кто виноват в ошибке с галереей? Клиент, потому что неправильно поставил задачу? Или менеджер проекта, потому что не уточнил ее?
Вот тут-то и появляется дилемма. Я написал 5 основных принципов постановки задач, которые планирую показывать всем нашим клиентам. Хотелось бы получить порцию критики или одобрения. С чем вы согласны? Что и где можно изменить, чтобы устранить пропасть в коммуникациях? Также буду рад ссылкам на другие источники с обсуждением/решением этой проблемы. Описанные ниже принципы постановки задач я рассматривал чисто в контексте нашей деятельности, но их можно без особого напряжения мозгов проецировать на любую область деятельности.
Основополагающий принцип при постановке задач. Я думаю, тут споров ни у кого не возникнет.
Фразы типа "Ну я имел это ввиду", "Да так везде, я думал, вы сделаете также" и "Я думал, это само собой разумеется" не являются аргументами. Вообще. Нужно четко описывать то, что вы хотите увидеть.
У этого правила есть минус - менеджер проекта может докапываться до любой мелочи и тянуть деньги с клиента .
Но клиент быстро заметит это и просто уйдет от нас. Терять заказ на 100 000 р из-за правок на 2 000 р очень глупо. Поэтому мы такой фигней не занимаемся.
Это отсеет кучу мелких и ненужных корректировок, а также некоторые крупные, но бесполезные задачи. Вообще, с нашей стороны менеджер всегда смотрит на фичи и может открыто сказать клиенту: "Это не принесет результата потому-то, потому-то, давайте не будем это делать". В краткосрочной перспективе мы получим меньше денег, в долгосрочной - довольного и лояльного клиента, который приведет своих партнеров.
Все знают про глухой телефон, и менеджер здесь является слабым местом. Обычно, мы используем для этого trello, где клиент ставит задачи, а менеджер может уточнять что-либо в комментариях. Финальная трактовка задачи заносится менеджером в ее описание. При этом разработчики видят все и могут проследить за ходом мысли клиента в комментариях за несколько секунд. Но с клиентом разработчики не общаются, чтобы не сбивать его с толку.
Нужно понимать, что избежать недопониманий или разных трактовок задач всё равно не получится. Обе стороны должны опираться не на эмоции, а на пользу для проекта. Все спорные ситуации решать исходя из этого принципа.
На этом все, жду интересных предложений