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

#1 Правильно ли вы поняли суть проекта?

Заказчики народ ленивый, а потому добиться от них подробной документации или спецификации будущего проекта непросто, особенно если проект небольшой. Зачастую менеджеры проектов получают, так называемую, user story. Потом этот документ усилиями менеджера или кого-то еще эволюционирует в спецификацию – более подробный документ с техническими терминами. И вот тут есть риск совершить первую, а зачастую и роковую ошибку – не поделиться этим документом с заказчиком. Ведь заказчик под словом “usability” имел ввиду не квадратную, а круглую кнопку! В лучшем случае такое недоразумение выльется вам в пару лишних часов работы, а в худшем – превышение бюджета/времени проекта, потеря/отказ от заказчика. Поэтому даже если вы и не планировали составить что-то похожее на спецификацию, то по крайней мере выслать скриншоты аналогов или описание проекта своими словами – было бы хорошим шагом в сторону от этих граблей.

#2 Не слишком ли часто, вы общаетесь с заказчиком?

Согласен, несколько противоречивый момент. В предыдущем пункте я рекомендовал дополнительно общаться с заказчиком, а теперь намекаю на то, что это не всегда полезно. Это действительно так. Наиболее плотное общение полезно в начале проекта, когда каждый участник, в том числе и заказчик пытаются понять и “построить” проект у себя в голове. Но дальнейшее общение по 2–3 часа в день может губительно сказаться на проекте, ведь во время этих дискуссий у заказчика появляются множество новых идей, не предусмотренных ни бюджетом, ни архитектурой проекта. Ежедневные вопросы “А в каком состоянии сейчас проект?”, “А кто над чем работает в данный момент?” и т.д. не только вызывают раздражение, но и отнимают и без того драгоценное время. И даже если заказчик отвлек вас всего на мгновение вопросом “А как пройти в библиотеку?”, то вам понадобиться от 10 минут до часа времени, чтобы вернуться в рабочее русло и восстановить свою производительность. Поэтому, если вам позовляет ситуация, ограничтесь общением по почте, оставьте номер телефона на пожарный случай – и никаких мессенджеров! Тем не менее онлайн общение необходимо на любом проекте – организуйте это в виде заранее спланированных коференц-звонков или собраний с точным регламентом по времени.

#3 Позволяете ли вы заказчику саботировать проект?

Заказчик может саботировать проект множеством способов – вносить в проект новые идеи или функционал; указывать вам как именно необходимо реализовывать ту или иную часть проекта; сокращать сроки сдачи работы и так далее. Был у меня один проект, на котором мы выполняли любую прихоть заказчика, крутили архитектурой проекта так, что через месяц ее было просто не узнать. А сам проект из узконаправленного решения превратился в некую платформу для решения “всех” проблем, в том числе и глобального потепления. Во время этого процесса заказчик был доволен как слон таблеткой, но как только подошло время первой бета-версии – он взгрустнул… Взгрустнул оттого, что бета не вышла, ведь последний месяц мы писали не запланированный функционал, а переделывали проект под новые идеи заказчика. В итоге все остались в проигрыше – мы без заказчика, заказчик – без продукта. Мораль проста – научитесь говорить НЕТ, даже если вы хотите угодить вашему клиенту.

#4 Дело дошло до спора?

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

#5 Что вы делаете, когда клиент недоволен?

Пытаетесь оправдаться? Перенести вину на заказчика? Доказать, что всему виной фаза луны? Все это, безусловно, пути решения проблемы, по которым иногда приходится идти. Но зачастую, наилучшим способом вернуть заказчика в прежнее, довольное состояние – это показать, что вы с ним одна команда и находитесь по одну сторону баррикад и, что вы заинтересованы в решении возникшей проблемы не меньше его самого. Даже если бюджет уже исчерпан, время подходит к концу, то фраза “да, это проблема, но мы поможем вам ее решить” заставит смотреть на вас с благодарностью. А следующая фраза “…но на это нам нужны будут новые $” будет звучать не так удручающе, как фраза “это не наша, а ваша проблема. Денег больше нет, помочь ничем не можем.”

И что с того?

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