Как же так? Еще вчера вы радовались тому, что, наконец-то, взяли наемных работников. Думали, появится время позаниматься глобальными задачами. Но все, как обычно, пошло не по плану.

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

А поможет нам в этом Плохой Начальник. Он все делает не так — учитесь на его ошибках!

Какие бывают задачи

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

Важные долгосрочные задачи

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

Важные текущие задачи

То, что можно сделать и завтра, но тянуть, все-таки, не стоит. Как пример: сменить поставщика, заключить договор с другой курьерской службой и так далее. Тоже требует определенной подготовки и планирования.

Ежедневные задачи

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

Прочие задачи

Переезд в другой офис, покупка новой кофе-машины, организация корпоратива — все это может и подождать. Сделать бы надо, но не горит. За исключением корпоратива, разумеется. Корпоратив — это святое. А все остальное легко можно отодвинуть на второй или даже третий план.

Как делает Плохой Начальник

Но не таков наш герой. Он валит все задачи в одну кучу и смешивает мух с котлетами. Принести в жертву важный проект и заставить заниматься корпоративом лучшего сотрудника? Легко.

Забыть о важной цели и сосредоточиться на сиюминутных перспективах? Без проблем. Ну можно же подождать полгода и не покупать новый “Мерседес”, а вложить деньги в развитие бизнеса. Но это же — Плохой Руководитель.

А “Мерс” такой блестящий и быстрый — как тут устоять. И друзья на таких ездят.

Как выглядит идеальная задача

Поручение должно быть внятно и однозначно сформулировано

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

А теперь попросите оппонента нарисовать то, что вы описали. Догадайтесь, насколько изображение будет близко к реальному облику вещи? Наверняка оно не будет напоминать его даже отдаленно. И это нормально.

С постановкой задач все то же самое. Если бросить менеджеру между дел “ты бы звякнул клиенту” — будьте уверены: позвонит не тому покупателю. Или не по той теме, которую вы имели в виду. У менеджера свои мысли и заботы, и он воспримет поручение по своему.

Поэтому максимум подробностей никогда не будет лишним. Рассказывайте детали и тонкости. Но не перегибайте палку. Как только заметили, что человек начал раздраженно кивать и в глазах читается “да понял я, понял” — прекращайте рассуждения.

Как делает Плохой Начальник

А он вообще никак не делает. Он не считает нужным раздавать текущие поручения. Считает, что персонал и так все знает. Менеджеры должны звонить покупателям, бухгалтер — считать прибыль и налоги, курьер — развозить товар клиентам. Зачем отвлекать людей от работы? Сами разберутся.

Плохой Начальник заходит в отдел по утрам, спрашивает, все ли в порядке и чинно удаляется. Зачем спрашивать о ходе выполнения задач и возможных проблемах — сами скажут, если что. Молчат — значит, все ок.

Задача должна быть ограничена во времени

Сотрудник всегда должен знать, сколько времени ему дается на выполнение задания. Поверьте: все ваши работники очень заняты и сами расставляют временные приоритеты. Все задачи делятся для них на срочные и не срочные. Забудете сказать, к какому времени нужно решить вопрос, и задача будет поставлена в конец очереди. А потом вам скажут: “ты же не сказал, что срочно”.

Лайфхак: никогда не ставьте крайние сроки. Если презентация назначена на 1 сентября, ни в коем случае не делайте дедлайн накануне.

Пусть ответственный сотрудник сделает проект к 20 августа. Это страховка на случай, если что-то пойдет не так — скорее всего, так и будет. Либо работник просто не успеет, либо сделает что-то не так.

А тут — бац! Есть время для маневра. Можно не спеша все доделать и исправить.

Как делает Плохой Начальник

Плохой Начальник начитался умных книжек, но ничего не понял.

Раз работники охотнее выполняют срочные задачи, значит все поручения нужно сделать срочными! Красота: на любое, даже самое пустяковое задание, сотрудники бросают все свои силы и умения.

На самом деле все происходит с точностью до наоборот: у подчиненных вырабатывается иммунитет на слово “срочно” и они перестают различать действительно важные задачи и те, которые могут подождать.

Задачи должны быть измеримыми

Разговаривать в формате “нам нужно поднять выручку” — не вариант. Нужно поднять — говорите, на сколько. До миллиона, до миллиарда — конкретно. Расширить штат сотрудников — на сколько штатных единиц. Открыть новые филиалы — сколько и в каких городах.

Только цифры, только конкретика. Если преподносить информацию абстрактно — толку не будет. Работники отчитаются о результатах, но цифры будут отличаться от тех, которые вы имели в виду. Поэтому показатели нужно озвучивать.

Особенно, если речь идет о количественных показателях.

Как делает Плохой Начальник

Наш герой собирает всех у себя на ковре и начинает топать ногами, делать серьезное лицо и устраивает разнос сотрудникам. Дескать, не такой рост он имел в виду. Не таких финансовых показателей ожидал от вас, растяп. Ну, а то, что не сказал сразу — так вы сами должны были додуматься, выжспециалисты. И за что я вам только деньги плачу?

Поручения должны быть выполнимыми

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

Сколько бы ни старались подчиненные, цель никогда не бывает достигнута. Вроде бы и результаты неплохие, а удовлетворения нет: задание не выполнено. Босс просил поднять продажи в 3 раза, а мы подняли только в 2 с половиной. Облажались, ничего не скажешь. Никому и не придет в голову, что поручение нельзя было выполнить в принципе. У всех в голове — только горечь поражения.

Если такое безобразие продолжается долго, это входит в привычку. Сотрудники перестают чувствовать вкус победы, радоваться достигнутым целям и праздновать результаты. Кругом только тлен и безысходность. Именно так хорошие работники становятся офисным планктоном. Еще пара штрафов за невыполнение плана — и готово.

Именно поэтому цели должны быть осязаемыми и достижимыми. Достигнутая цель — это как один шаг навстречу большой идее. Сотрудники должны видеть результаты своей работы. Если этого не будет — они потеряют интерес.

Как ставить задачи — полезные советы предпринимателям

Выбирайте время и место

Убедитесь, что сотрудник, которому выдается поручение, готов вас видеть и слышать. В идеале нужно раздавать задания в одно и то же время. Лучший вариант — оперативные совещания. Работники всецело ваши, слушают, записывают и усваивают информацию.

Как делает Плохой Начальник

Он фурией врывается в офис и бежит к первому попавшемуся менеджеру. Неважно, что то разговаривает с клиентом по телефону и вряд ли готов выслушать. Он вываливает на бедолагу поток своих мыслей и чинно удаляется. Менеджер, положив трубку, спрашивает у коллег: “А что шеф то прибегал?”. Он ничего не услышал и не понял. А Плохой Начальник уверен в обратном.

Соблюдайте субординацию

У вас есть отдел продаж, во главе которого стоит начальник отдела. Он подчиняется вам, а ему — менеджеры по продажам. Раздавайте поручения относительно работы продажников начальнику отдела, а не его подчиненным. Помните древнее правило: вассал моего вассала — не мой вассал.

Как поступает Плохой Начальник

Наш герой считает, что он главный босс, а значит, ему подчиняются все. Вообще все. Он дает указания уборщицам относительно мытья полов, менеджерам — касательно отношений с клиентами, а водителям напоминает правила дорожного движения. Бежит впереди паровоза, только наоборот.

Простой менеджер не может ослушаться хозяина — все-таки он тут решает все. Приходит горе-босс, говорит — “звони клиенту” — и тот приступает к выполнению распоряжений. Только вот беда в том, что тот забыл предупредить начальника отдела, что его подчиненный делает не ту работу, которую ему поручил непосредственный руководитель. И все идет наперекосяк.

Грамотно выбирайте адресатов

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

Как действует Плохой Начальник

Наш герой нервно курит в сторонке. Он слабо разбирается в делегировании полномочий, поэтому поручает задачи всем подряд, вне зависимости от статуса и сроков. А если сомневается — пытается тащить все сам. Потом жалуется, что ничего не успевает.

Назначайте ответственных

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

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

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

А надо было, всего лишь, назвать фамилии ответственных сотрудников. Петров, ты отвечаешь за это, а ты, Иванов — за то. В идеале составить протокол оперативного совещания и собрать подписи. Чтобы не отвертелись.

Хвалите и мотивируйте персонал

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

На самом деле похвалить сотрудника, отлично справившегося с заданием — совершенно нормально. Это мотивирует к дальнейшим свершениям. В сознании формируется четкая связь: сделал хорошо — начальник заметил и оценил.

Можете мотивировать на опережение. Если сказать работнику: “Ты получил это задание, потому, что хорошо справился с прошлым поручением и я тебе доверяю” — он свернет после этого горы.

Подытожим

Раздавать поручения не так просто, как кажется на первый взгляд. Не берите пример с нашего героя. Этот несерьезный собирательный образ мы придумали для того, чтобы показать вам возможные ошибки. Если вы узнали себя в Плохом Начальнике — пора задуматься о смене формата общения с персоналом. Удачи!

Как взяться за задачу и не облажаться

Можно по разному относиться к «Бюро Горбунова» и его апологетам, но в одном им не откажешь — в Бюро умеют чётко формулировать идеи и их придерживаться.

Это касается и методологии ФФФ (которую, впрочем, придумали в 37Signals), и принципов «делать ≠ сделать» или «исполнитель понимает задачу». Последний принцип особенно важен.

Мало кто пытается на решить задачу клиента, а не просто её сделать. И это проблема.

Зачем понимать задачу

В идеальном мире работа над задачей происходит так:

• клиент ставит исполнителю задачу,
• исполнитель задачу делает,
• клиент принимает результат и все счастливы.

Но в реальности клиент не принимает задачу, потому что исполнитель что-то сделал не так. Исполнитель переделывает, клиент снова недоволен, снова переделка и так пока клиент и исполнитель не придут к компромиссу или не разругаются. Так происходит из-за того, что клиент и исполнитель по-разному смотрят на задачу:

• чаще всего, клиент слабо вдаётся в подробности (а если вдаётся, говорит о том, что хочет, но не о том, какую проблему нужно решить);
• даже если клиент даст исполнителю самое подробное ТЗ на свете, тот всё равно может всё понять по-своему (но не потому что дурак, а потом что все люди разные).

У меня так часто бывает дома. Например, жена просит на обратном пути с работы купить йогурт. Я приношу питьевую Активию, и она недовольна — ей-то нужен был йогурт в стаканчике, чтобы заправить салат. В результате мы оба расстроены и битый час друг с другом не разговариваем.

Проблема и в ней, как в клиенте (недостаточно чётко объяснила, какой йогурт нужно купить), но по большей части во мне, как исполнителе — я не задал уточняющие вопросы, не разобрался в задаче.

И если в семейной жизни можно сказать клиенту, что это она виновата — плохо объяснила, — то на работе виноват в такой ситуации всегда исполнитель.

Исполнитель всегда должен понимать задачу.

Единственный способ исполнителю удостовериться, что он правильно всё понял — задать клиенту вопросы и озвучить (или написать) своё понимание. Если клиент подтвердит, можно смело приступать к работе.

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

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

Как задавать вопросы

К пониманию задачи можно подходить по разному, в зависимости от сложности. Главное — убедиться, что ты всё правильно понял.

Можно коротко задать вопросы в чатике, сформулировать суть и договориться о сроках, а можно составить подробный многостраничный гуглдок со всесторонним описанием задачи.

Для типовых задач у тебя даже может быть заготовлен список вопросов, ответы на которые прояснят картину. Например, у Бюро есть вопросы, которые они задают клиентам в самом начале. У тебя могут быть те же четыре темы для вопросов:

• Бизнес. Узнай, как работает компания, как зарабатывает и где берёт клиентов. Нужно представлять компанию не только снаружи, но и изнутри.
• Проблема. Узнай больше о задаче: почему она возникла, в какие сроки её нужно решить и почему именно её. Тебе нужно хорошо разобраться в причинах, которые стоят за клиентской задачей на случай, если проблема вообще в другом.
• Ожидания. Узнай, что клиент ожидает от результата задачи. В каком случае он будет считаться успешным, а в каком нет? Возможно, у него есть примеры, которые нравятся.
• Решение. Узнай, как, на взгляд клиента, можно решить задачу и почему. Уточни, кто будет согласовывать результат, и какие сложности по пути могут возникнуть.

Но это всё очень примерно. В каждом проекте, в каждой задаче вопросы могут быть разные, потому что прояснять нужно будет разные аспекты. Главное задавать вопросы вежливо и открыто, чтобы клиент не умолчал о важном.

Что должно быть в понимании задачи

Чтобы синхронизировать видение, исполнитель описывает всё, что понял из ответов на вопросы, в специальном документе, который и называется пониманием задачи.

Если задача сложная или новая для исполнителя, понимание может быть большим. Максим Ильяхов в одном из уроков Главреда говорит о пяти частях:

• Компания. Коротко о том, чем занимается клиент.
• Проблема. Почему нужно делать задачу, что с её помощью планируем решить.
• Задача. Что нужно сделать для решения проблемы. В каком виде должен быть результат для клиента.
• Решение. Кто и что конкретно будет делать для решения проблемы.
• Проверка. Какой результат ожидаем получить. Как будем его проверять.

Но на действительно больших и сложных задачах я предпочитаю придерживаться чуть более подробного понимания:

• Клиент. Что за клиент и проект.
• Результат. Каких измеримых показателей хотим достичь. Как поймём, что достигли.
• Полезное действие. Кому и зачем всё это нужно.
• Ограничения. Какие технические и бизнес-ограничения нужно учесть.
• Риски. Какие есть риски. Как их снизить.
• План. Кто и что конкретно будет делать для решения задачи.
• Ресурсы. Что нужно для старта работ. Что потребуется в процессе.
• Участники. Кто за что будет отвечать?

Впрочем, если это небольшая задача или задача, которую ты уже неоднократно делал, обычно достаточно пары предложений.

Когда понимание готово, исполнитель отправляет его клиенту, тот исправляет ошибки и неточности и согласовывает. Теперь у клиента и исполнителя в голове рисуется один и тот же результат.

Главное — не забивай на понимание вовсе. Оно в любом случае тебе поможет прийти к ожидаемому результату за нужное время: будь ты хоть клиент, хоть исполнитель.

Исследования подтверждают: если вы хотите быть продуктивнее, в первую очередь следует браться за более сложные задачи

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

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

Однако они считают, что данная стратегия не окупается в долгосрочной перспективе.

«В краткосрочной перспективе человек действительно может чувствовать себя удовлетворенным, менее тревожным. Но бесконечное избегание трудных задач также лишает человека возможности учиться и совершенствовать свои навыки.», — рассказала Коучаки.

«С точки зрения долгосрочной перспективы, такое поведение не в интересах ни отдельного человека, ни группы, ни организации. Эта часть обучения крайне важна», — добавила она.

Чтобы избежать этого соблазна, руководители должны поощрять работников решать сложные задачи и разбивать проекты на кусочки, чтобы сотрудники по-прежнему получали удовлетворение от завершения каждого шага, утверждает Коучаки.

«Вы должны подходить к планированию более тщательно, чтобы убедиться, что люди получают возможность учиться, что они испытывают свои навыки», — рассказала она. Сотрудник, который каждый день выполняет множество простых задач, может казаться продуктивным, но «в конечном счете, это не приносит плодов».

Какими задачами заниматься в первую очередь – легкими или сложными?

Идея для исследования возникла, когда Коучаки беседовала с Брэдли Стаатсом из Университета Северной Каролины в Чапел-Хилле и Франческой Джино из Гарвардской школы бизнеса о своей собственной тенденции откладывать трудные задачи в пользу легких.

Например, она могла бы заниматься подготовкой к преподаванию, вместо написания статьи. «Когда мы перегружены и заняты, мы просто склонны к решению более легких задач, а сложные задачи, как правило, только накапливаются», — рассказала Коучаки.

Исследователи задались вопросом, было ли это предубеждение широко распространено. Если да, то каковы были краткосрочные и долгосрочные результаты такого стиля работы?

Чтобы выяснить ответ на этот вопрос, они приступили к сотрудничеству с К. Дивасом из Университета Эмори и сосредоточились на том, как врачи больницы выбирают себе задачи.

Исследователи получили данные о 84 врачах, которые лечили более 233 000 пациентов в отделении неотложной помощи восточного побережья с 2005 по 2010 год. Когда пациенты поступали в отделение скорой помощи, медсестра назначала им уровень сложности. Вероятно, большая сложность случая соответствовала более сложной задаче.

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

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

Во-вторых, они исследовали меру, называемую относительными единицами стоимости (RVU). Больницы и социальные клиники используют этот показатель для изучения таких факторов, как время, навыки и усилия, затраченные на один случай.

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

Затем команда проследила, как решения врачей, по-видимому, влияют на их производительность как в краткосрочной, так и в долгосрочной перспективе.

Ложное чувство прогресса с более легкими задачами

Как и предполагали исследователи, наличие более высокой рабочей нагрузки увеличивало вероятность того, что врач выберет более легкого пациента.

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

Кроме того, чем больше был показатель RVU, тем больше была вероятность того, что врач выберет более легкого пациента.

Но от этого пострадала долговременная работоспособность врачей.

Исследователи проанализировали послужной список каждого врача за шестилетний период исследования. Неудивительно, что время работы врачей, как правило, сокращалось, поскольку они завершали больше случаев с течением времени, предполагая, что они становятся более эффективными.

Но когда врачи включили большую долю трудных случаев в их общую нагрузку случая, «эффект ускорения» выражался сильнее, обнаружили исследователи. Кроме того, врачи, которые брали на себя более высокую долю сложных случаев, как правило, генерировали больше RVU на одного пациента в будущем.

«Врачи, которые занимаются более трудными пациентами – это те, кто с течением времени учится, они генерируют большую ценность для больницы», — рассказала Коучаки.

Чувство усталости

Исследование в больнице было интригующим, но у него было несколько недостатков.

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

Действительно ли именно усталость заставляла врачей выбирать более простых пациентов во избежание слишком напряженной смены? А как насчет желания ощутить чувство прогресса или стресса?

Для выяснения этих вопросов группа провела второе исследование в режиме онлайн.

Они набрали 365 участников, которым было предложено прочитать боковое изображение страницы книги и напечатать как можно больше текста за три минуты.

Половину группы попросили одновременно прослушать песню и подсчитать количество раз, когда были использованы определенные слова, что значительно увеличило рабочую нагрузку.

После этого все участники заполнили анкету, чтобы сообщить о своем чувстве прогресса, усталости и уровне стресса. Затем каждый человек должен был выбрать второе задание: одно, как им сказали, было относительно легким, а другое несколько трудным.

В группе с высокой нагрузкой 76% участников выбрали «легкую» вторую задачу по сравнению с 64% в группе с низкой нагрузкой.

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

«Здесь речь больше шла о чувстве прогресса и усталости», — рассказывает Коучаки.

Детские шаги

Эти результаты говорят о том, что руководители должны просвещать сотрудников о важности решения сложных задач для профессионального роста, рассказала Коучаки.

Речь идет о «мотивации и помощи в понимании того, что это важно для долгосрочного обучения и эффективности», рассказала она. Разбивка сложных проектов на мелкие этапы может помочь дать работникам высокую степень завершения, которую они получают от простых задач, в то же время обеспечивая испытания и возможности для развития.

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

В своей собственной работе Коучаки старается обеспечить приоритетность сложных задач. Но это не значит, что она игнорирует самые простые. В конце концов, черную работу все еще нужно сделать. И когда она застревает на сложном проекте, иногда она выполняет простую задачу, чтобы дать себе импульс.

«Чувство прогресса – это очень важно», — заявила она.

18+ вопросов заказчику, которые нужно задать перед началом работы

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

1

Когда-то давно я начинал с фриланса, а сейчас собираю проектные команды, и могу сказать — неважно, берётесь вы за масштабную разработку или выполняете небольшую задачу — алгоритм всегда один.

Первым делом поймите, какую проблему заказчика вы решаете. Здесь хитрость в том, чтобы не путать задачу и решение. Часто бывает так, что вам не называют проблему, но говорят, как её решить: просят сделать сайт или приложение.

А задача на самом деле — сократить издержки, увеличить продажи. Эти вещи нужно связать, чтобы проверить работоспособность предложенного решения.

Будет ли всё работать так, как это представляет себе заказчик? Задавайте открытые вопросы, но без фанатизма, никто не любит на них отвечать.

• Максим Мул, финансовый директор Work Solutions
• 2

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

1. Максим Мул, финансовый директор Work Solutions
2. 3

Заказчик должен сразу озвучить, в какие сроки хочет получить готовый проект. Он может быть недостаточно компетентен в сфере разработки. В таком случае сроки рассчитывать вам. Предупредите, что оценка времени — это тоже время, и ваш анализ сложности задачи также должен быть включён в бюджет.

Обязательно спрашивайте о сроках. Остерегайтесь проектов, по которым нет дедлайна — это сигнал о том, что проект никому не нужен и сдать его будет очень непросто.

• Максим Мул, финансовый директор Work Solutions
• 4

Может показаться странным, но иногда такая вещь бывает неочевидной, в то время как техническое задание пестрит скупой формулировкой. Это один из тех вопросов заказчику, которые помогут определить сложность поставленной задачи.

1. 5
2. Это важно, так как отсутствие документации и, тем более, разработчика, который занимался проектом до вас, значительно усложнит задачу, что повлияет на сроки и итоговую стоимость.
3. 6

Если соотношение сложность/бюджет из разряда фантастики, лучше оговорить это заранее. До обсуждения оценка сложности уже должна быть выполнена, чтобы грамотно аргументировать свою точку зрения.

• 7
• Этот пункт включил сразу пять вопросов клиенту, с помощью которых вы сможете выяснить, насколько всё готово для старта работы над проектом с его стороны.
• На старте любого проекта важно оценить не только свои силы, как исполнителя, но и понять готовность заказчика к проекту.
• Вот то, что нужно уточнить у заказчика в первую очередь:

1. Техническая готовность. Насколько ИТ-инфраструктура заказчика надёжна, обладает ли она достаточной мощностью для реализации будущего проекта.
2. Функциональная готовность. Насколько выстроены функциональные и бизнес-процессы в компании, которые будут задействованы при реализации проекта.
3. Нормативная готовность. Приведены ли в порядок внутренние регламенты и нормативная документация предприятия, необходимые для проведения работ.
4. Информационная готовность. К ней относится уровень качества предоставляемой информации. Насколько подготовлены исторические данные, задействованные в работах и влияющие на процесс и результат проекта. Какова информированность всех участников проекта о предстоящих целях, действиях, процессах, изменениях, результатах.
5. Ресурсная готовность. Достаточная вовлечённость выделенных со стороны заказчика специалистов (компетентность и высокая мотивация как в участии в проектных работах, так и в конечном результате). Заинтересованность в проекте топ-менеджеров заказчика.

Задав эти вопросы на старте проекта заказчику, вы можете наиболее точно сформировать его ожидания. В зависимости от ответов на них, скорректировать содержание проекта, продумать превентивные меры, предупредить риски или вовсе задуматься об отказе от проекта.

1. Елена Шишкова, начальник отдела развития и внедрения ERP-решений CorpSoft24
2. 8

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

9

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

10

Этот вопрос заказчику нацелен на правильное построение коммуникации. Всевозможные созвоны, доступы к документам или сервисам, отчётность — всё это зависит от команды, которая задействована в реализации проекта.

11

Важно в самом начале также ответить на вопрос: «А чего система НЕ будет делать?» Кто-то скажет: ответ очевиден — система не делает ничего, кроме того, что в ТЗ. Но нет, для многих заказчиков это не вполне очевидно, и между строк они зачастую видят много чего сверх.

• Евгений Лопатин, руководитель Центра программных решений «Инфосистемы Джет»
• 12

Такой вопрос стоит задать заказчику, если он понимает процесс разработки, это проект не с нуля, или его команда работает с какими-то конкретными инструментами. Допустим, вы привыкли всё хранить в репозиториях на GitHub, а команда заказчика работает с Bitbucket, или он вообще не хочет, чтобы во время разработки проект выходил за пределы локали.

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

Приведу простой пример: представьте, что для технического проектирования внедряемой системы вы всегда используете требования ГОСТа, и в очередной раз оформляете документ по стандарту.

В момент его согласования вы узнаёте, что у заказчика для него есть свой утверждённый корпоративный шаблон, который содержит специфичные разделы и особое оформление.

Вы не задали вопрос заранее, и теперь придётся потратить дополнительное время на исправление результатов.

1. Валерия Суворова, эксперт Центра информационной безопасности компании «Инфосистемы Джет», сертифицированный менеджер проектов (PMP)
2. 13

Часто случается так, что заказчик стремится минимизировать расходы и начинает подключать своих людей в середине работы. Это неправильно. Уточните сразу, примет ли ещё кто-то участие в самой разработке, и если да, как это будет спланировано.

14

И ещё один важный вопрос — а что потом? Любая система предполагает развитие. Спросите, как видит развитие и будущее системы заказчик. Каким бы преждевременным ни казался такой разговор, он может существенным образом повлиять на архитектуру уже сейчас.

• Евгений Лопатин, руководитель Центра программных решений «Инфосистемы Джет»

Дополнительные вопросы заказчику: отвечают эксперты

Сергей Комаров

руководитель департамента информационных решений РДТЕХ

Расскажу с точки зрения проектов заказной разработки. Основные проблемы, с которыми можно столкнуться, не уточнив детали постановки задачи у заказчика, — это выход за рамки бюджета и срыв сроков проекта. Как результат — исполнитель доделывает всё в авральном режиме и за собственный счёт, чтобы спасти свою репутацию. Согласитесь, не очень привлекательная картина.

Сложно дать исчерпывающий список вопросов, с которыми можно пойти к заказчику, т. к.

это сильно зависит от многих факторов: будет ли система разрабатываться с нуля или это развитие уже существующей системы, есть ли у заказчика конкретные пожелания к платформе, на которой будет выполняться разработка, планирует ли заказчик каким-либо образом принимать участие в проекте (помимо своей основной роли — заказчика работ) и многое, многое другое. Ответы на вопросы формируют наше понимание задачи, т. е. область охвата (или скоуп) будущего проекта. И чем это понимание глубже, тем меньше рисков, что что-то мы не учли или что-то пойдёт не так.

В числе основных проблем, которые я упомянул в самом начале, было две: выход из бюджета и срыв сроков.

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

Ответы на эти вопросы задают граничные условия проекта и позволяют задать вектор дальнейших обсуждений. Например, если сроки чрезвычайно сжатые, то можно обсуждать подход MVP (Minimum Viable Product — минимально жизнеспособный продукт).

Дальнейшие вопросы можно условно разделить на две группы: первая — это требования непосредственно к системе, а вторая — это вопросы, относящиеся к организации работ.

Причём вторая группа вопросов влияет на проект ничуть не меньше первой.

Самое главное — не стесняться задавать вопросы и задать их нужно ровно столько, сколько необходимо для понимания, возможна ли реализация задачи в заданные сроки и бюджет.

Михаил Сарычев

директор по развитию DBI

Перечень конкретных вопросов очень зависит от специфики проекта.

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

Особенно это касается интеграционных компонентов и систем, созданных заказчиками самостоятельно, «с нуля».

Я рекомендую получать максимальную информацию о таких программных продуктах: очень часто их описание не задокументировано, а ответы на вопросы хранятся только в головах их разработчиков. Часто, работая с собственными разработками заказчиков, мы недооценивали сложность интеграции или в самый последний момент узнавали о том, что программный продукт реализован на старой или редкой технологии, которую в нашей компании мало кто знает.

Несколько важных вопросов, которые мы спрашиваем у клиента всегда, вне зависимости от специфики проекта:

1. Кто внутренний заказчик (так как с запросом может прийти ИТ, а использовать продукт будет, например, маркетинг)?
2. Второй важный вопрос: есть ли верхнеуровневое ТЗ и видение конечного результата у заказчика, а также чётко сформулированные критерии успеха проекта.
3. Если ТЗ уже готово, и проект достаточно проработан, то присутствует ли на проекте ещё кто-то из подрядчиков по смежным направлениям, связанным с данным проектом? Это важно понимать для построения правильной коммуникации, координации и планирования.
4. Есть ли специфические требования у отдела службы информационной безопасности заказчика? Сроки предоставления доступов, возможность работать удаленно, какие технологии и подходы одобрены в компании и т. д. В подавляющем большинстве случаев проходить согласование со службой безопасности перед приёмкой проекта придётся, поэтому лучше уточнить все требования «на берегу», чтобы потом не было неприятных неожиданностей.

По нашему опыту, отсутствие ответов на эти вопросы приводит к целому набору проблем: затягивание сроков старта проекта из-за несвоевременного предоставления доступов; расхождения в понимании конечного результата и ожиданий клиента; сложности в дополнительной координации и коммуникации и затягивание сроков из-за задержек на стороне других участников проекта; неверная постановка задач от ИТ-службы заказчика в связи с расхождением в понимании требований между айтишниками и конечными пользователями проекта.

Руслан Сумцов

руководитель отдела аналитики и проектирования решений Bercut

Проекты компании Bercut — это b2b категория. Поэтому прежде всего важно понимать, что заказчиком для нас является целая компания, то есть большое количество людей с разными задачами, интересами и целями. Всё это должно быть учтено в нашем решении.

Говорим с бизнес-заказчиком

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

ТОП-4 вопроса для бизнес-заказчика:

1. Какую бизнес-задачу должен решать продукт? Или какие ограничения для бизнеса должен устранять?

Пример бизнес-задачи. Наше решение MNP (Mobile Number Portability) решает задачу автоматизации переноса данных при сохранении номера абонента, когда он меняет оператора.

По мнению заказчика, эта услуга должна упростить привлечение новых клиентов, дать оператору доступ к абонентам, которые оставались вне конкурентного поля, позволить анализировать поведение абонента и оперативно реагировать на его желание сменить оператора. И при этом не сыграть против самого заказчика.

2. Какова стоимость проекта?

Выяснить ожидания по стоимости проекта необходимо, даже если заказчик говорит, что стоимость не важна или затрудняется назвать сумму. Дело в том, что цена сильно влияет на основные параметры продукта, на используемые технологии.

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

3. Срок. Когда решение должно достигнуть результата?

Так же, как и стоимость, длительность может стать как ограничителем всего проекта и поставляемого решения, так и дать дополнительные возможности.

4. Готов ли заказчик что-то менять в компании в связи с поставкой решения?

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

Говорим с техническими специалистами

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

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

Но оно оказалось неоптимальным с точки зрения эксплуатации. Обучение инженеров работе с системой оказалось настолько дорогим и долгим, что могло нивелировать бизнес-ценность.

Команде пришлось возвращаться к аналитике и расширять возможности решения уже с учётом требований и ожиданий тех, кто им пользовался.

Я считаю, чем больше представителей заказчика из группы эксплуатации участвует в формировании требований и чем раньше мы включаем этих людей в проработку требований, тем лучше результат.

Вот мои ТОП-5 вопросов для технических специалистов заказчика:

1. Какие должны быть использованы технологии?
2. На каком уровне необходимо решать вопросы безопасности?
3. Планы по нагрузке (число пользователей)?
4. Как пользователи видят свою работу с решением, какие задачи важно решить?
5. Что важно получить от решения для эффективной повседневной работы с ним?

Аналитику важно помнить, что любое решение делается для людей и ради людей.