Самая сложная часть это удержать заказчика, когда он сделал первый пробный шаг в сотрудничестве с вами, но ещё не привязан к вам сколько-нибудь серьезно. Я расскажу о наиболее частых ошибках и удачных моделях поведения в работе с клиентом. Это опыт наших разработчиков, вынесенный из множества мелких и средних проектов.
Рассмотрены, в основном, сугубо технические моменты, никакой техники продаж и прочего маркетинга.
Некоторые вещи могут показаться очевидными, но для неопытного разработчика могут стать если не открытием, то хорошей подсказкой в нужный момент. По признанию приглашенных спикеров, даже опытные разработчики, бывает, упускают возможности, совершая стандартные ошибки из года в год. По отзывам студентов с курса мы подумали выложить материал здесь в виде тезисов.
Аналитический разрыв
Заказчик подразумевает, что вы знаете очевидные для него вещи, о которых он умолчит, но будет много рассказывать вам про несущественные детали. Вам нужно максимально прояснить для себя важные для вас тонкости его бизнеса: уловить суть процесса.
Первый контакт
Вы не можете быть экспертом в бизнесе заказчика, можете не знать его технологии и системы, с которыми нужно будет интегрироваться. Тем не менее, вы должны описать заказчику предстоящий проект так, чтобы он поверил в его осуществимость.
Вы должны выглядеть профессионально. Это несложно сделать.
После краткого описания задачи заказчиком вы принимаете решение. Если проект понятен и может быть решен вашими силами, то есть, например, там нет требования написать драйвер на С++ или разработать математическую модель на незнакомом вам языке, то вы двигаетесь дальше. Иначе вы расстаетесь не беритесь за то, что не можете оценить.
Если перед вами реализуемый проект, то вы описываете как вы его будете делать:
-
Вы возьмете день-два на подготовку состава решения это рамки проекта
-
По составу решения сделаете оценку проекта в днях и деньгах
-
Возможно, вы предоставите первый прототип вместе с составом решения
-
Составите план проекта очень простой документ
-
Обговорите вопрос о собственности на разработку задайте такой вопрос
-
Напишете для пользователей инструкцию по продукту
-
Договоритесь о гарантийном сроке и формате технической поддержки
Получив четкое видение проекта, заказчик будет больше доверять вам как разработчику. Многие вопросы и сомнения в вашем опыте и способности сделать работу отпадут сами.
Состав решения
После первой встречи с вы фиксируете краткое описание задачи и перечисляете объекты и процессы, которые будут созданы в рамках проекта.
Рекомендуем делать совсем простой документ, он не является техническим заданием (ТЗ), но фиксирует основные моменты, которые обсуждались на встрече с заказчиком.
Фрагмент документа, ограничивающего рамки проекта|
Участок, процесс или модуль системы |
Решаемая задача / функционал системы |
|
Система в целом |
В системе будут реализованы: |
|
Номенклатура |
Будет использоваться единый справочник номенклатуры для синхронизации 1С и проектируемой системы. Должна быть продумана методика простой и надежной идентификации продукции, включая разделение внутренних и оригинальных штрих-кодов, нескольких версий артикулов и фото изделий. |
|
Проект/Договор |
Проект является верхним уровнем иерархии. В рамках проекта реализуются работы, составляются сметы, акты о приемке работ и справки о стоимости выполненных работ и затрат. |
Это не всеобъемлющий документ. Его задача ограничить рамки проекта, чтобы оценить его более или менее точно.
Вы не опускаетесь до атрибутов объектов, описывая состав решения. Вы можете добавить сколько угодно атрибутов, и это не займет много времени. А вот реализовать процесс с вовлечением каких-то новых объектов может оказаться нетривиальным и сильно повлияет на ваши трудозатраты.
В ходе выполнения проекта вы можете возвращаться к этому документу и сверяться с заказчиком, какие работы были запланированы, а какие являются новыми требованиями и должны быть оценены и оплачены дополнительно.
Оценка трудоемкости и её обсуждение
Со временем вы научитесь быстро оценивать затраты на проект, а на первых порах я рекомендую вам засекать время выполнения задач, обращая внимание на трудности, с которым вы сталкивались во время работы.
Оценку важно давать с запасом! Вы неизбежно будете сталкиваться с трудностями, на преодоление которых понадобится время.
Самая быстрая работа это организация структуры данных, которая занимает считанные часы. Самая долгая это разработка и верстка рабочих мест. Большие риски связаны с интеграцией, при которой вы можете долгое время решать самые неожиданные проблемы. Не забывайте, что вам необходимо протестировать все ваши изменения, для чего может понадобиться подготовка данных и последующая очистка системы от них.
Трудоемкость импорта данных заказчика зависит от количества атрибутов, а максимальное требуемое на импорт время можно приблизительно рассчитать так: 15 минут на каждый атрибут. Например, импорт двух таблиц из 8 колонок каждая займет у вас не более 4 часов.
Важность составления плана
Необходимо составить план проекта, которого вы будете придерживаться. План содержит сроки, текущее состояние задач и ответственного. Это должен быть достаточно простой и наглядный документ, чтобы обновление и прочтение его занимало не больше двух минут. Достаточно 5-6 пунктов, чтобы у вас было одинаковое понимание где вы находитесь сейчас, на чьей стороне мячик и какой шаг следующий.
План дисциплинирует и вас, и заказчика, устраняет разногласия на ранней стадии.
Не гонитесь за средствами автоматизации: планировщиками, трелло, jira и подобными, если только они уже не используются у заказчика и он к ним привык. В той стадии, где мы с вами сейчас для наших проектов и заказчиков список текущих задач достаточно вести на листе блокнота или в табличке вашего приложения, там же, где вы делаете проект.
Техническое задание
У заказчика, возможно, уже есть техническое задание. Иногда он планирует, что вы его подготовите за него, потому что просто не имеет опыта в составлении таких документов.
Если ТЗ есть, то изучите его внимательно и, по возможности, не отходите от его требований. В исключительных случаях вы можете рекомендовать заказчику внести изменение в ТЗ, если это значительно влияет на проект в лучшую сторону и вы уверены, что сможете это реализовать (у вас должен быть положительный опыт в подобном).
Позвольте дать несколько спорный совет, который, тем не менее, отлично работает:
Не рекомендуется участвовать в составлении ТЗ, потому что это накладывает на вас дополнительную ответственность. Если в программировании у вас есть значительное преимущество перед конкурентами-подрядчиками вы делаете всё быстрее и проще, то в составлении ТЗ у вас такого преимущества нет.
Техническое задание часто пишется в отрыве от реального мира и его сложностей, поэтому его не всегда можно реализовать, оно пишется долго и быстро устаревает.
Когда вы описали состав решения и быстро делаете то, что устраивает заказчика, то он забывает о ТЗ и начинает воспринимать весь продукт как живое ТЗ он сказал мысль, которая немедленно материализовалась вами и эта материализация стала доступна пользователям.
Понятие MVP
Минимально жизнеспособный продукт продукт, обладающий немногочисленными, но достаточными для удовлетворения первых потребителей функциями. Основная задача получение обратной связи для формирования гипотез дальнейшего развития продукта.
Заказчик ждёт сияющий храм на холме, при этом он довольствуется тесной квартирой в многоэтажке, где его многое не устраивает. Вы ему построите просторный дом, лучше его квартиры, но начнете вы с шалаша с минимальными удобствами.
Заказчик должен как можно раньше начать пользоваться результатом так вы получите ценную обратную связь и сможете корректировать продукт, быстрее приближая его к идеалу. Удовлетворенность заказчика при этом должна постепенно расти.
Картинка про MVP вызывала споры на Хабре, однако для небольших проектов, где при каждой итерации переделывается большая часть сделанного и добавляется ещё столько же, она вполне близка к реальности.
Итерации эволюция продукта
Хорошо бы сразу обрисовать общие очертания будущего проекта, в результате чего заказчик видит свои живые данные, работающие в новой системе. Не замахивайтесь на многое покажите первый результат как можно быстрее.
В качестве первой итерации вы можете сделать простой справочник клиентов, контрактов, задач и ответственных часто это уже решает некоторые проблемы CRM заказчика.
Интеллектуальная собственность
Важно сразу договориться о дальнейшем использовании результатов вашего совместного с заказчиком труда. Это именно совместный труд: заказчик делится с вами своей экспертизой ценными для его бизнеса знаниями, а вы программируете всё это.
Более-менее крупный заказчик сразу предъявит право единоличного использования результатов проекта. В большинстве случаев он сам хочет его продавать своим коллегам в отрасли. Он знает как нужно делать, но пока не смог это сделать. Это сделаете вы.
Как это бываетНапример, любая строительная компания имеет своё видение, как эффективно построить процесс, и обращается к вам для воплощения своего видения. Разумеется, это воплощение интеллектуальная собственность, поэтому вы должны гарантировать заказчику, что не будете тиражировать проект без его согласия. Для такой гарантии достаточно всего нескольких предложений в договоре, однако мы неоднократно видели сорванные сделки из-за невозможности договориться.
В подобном случае объясните заказчику, что у вас иной бизнес и вы не его конкурент, а также предложите внести в договор, что вы не будете копировать наработки проекта.
Сложный проект вам всё равно будет проще сделать с нуля, чем адаптировать.
Оговорите, какие материалы вы сможете показывать вовне, например фрагменты инструкций.
Мнимые сложности
Часто заказчик будет вам рассказывать, как сложен его бизнес-процесс, сколько в нем всяких тонкостей. Вам нужно понимать разницу между сложностью процесса и сложностью отдельных операций. Многие проблемные места в работе заказчика порождены не сложностью его бизнеса в целом, а трудоемкостью операции, которая выполняется на каком-то этапе работ.
Пример ложных сложностейНапример, составить список для обзвона клиентов это отдельная незначительная операция. Однако, существующий в компании порядок выделяет её в отдельный сложный процесс сверки нескольких списков и ручной подготовки отчета. Такой отчет может готовиться в течение половины дня, а устаревает через несколько часов после начала обзвона. И всё начинается сначала. Для заказчика это трудоемкая часть основного процесса. Если таких частей много, то весь процесс выглядит сложным и непостижимым для восприятия.
Вы заменяете эту операцию одним отчетом он делается нажатием кнопки и всегда актуален. Затем выделяете следующее такое проблемное место, ещё и ещё. Заказчик избавляется от мелких головных болей и сосредотачивается на главном.
Вы привыкнете мысленно делать это в ходе переговоров выделять проблемные места в основном потоке дел и устранять эти сложности, очищая бизнес-процесс.
Отчеты и информационные табло
Не забывайте про то, что заказчику важен контроль над происходящим в его системе. Чтобы он не работал вслепую, ему понадобится некоторое количество отчетов о здоровье его бизнеса. Какие-то отчеты он сможет делать сам, но большинство из них вам нужно будет подготовить самостоятельно.
Важно не забыть включить всё это в оценку.
Разработка отчета обычно занимает не более нескольких минут. В сложных случаях можно провозиться 2-4 часа. По опыту, даже в простых приложениях очень быстро появляется до полутора сотен и больше различных отчетов. ***
*** Здесь имеется в виду разработка в low-code конструкторах, у которых своя специфика построения отчетов и структур.
Разработка информационного табло занимает больше времени, поскольку вам придется работать с его дизайном, а это не всегда бывает просто. Всегда запрашивайте макет табло будет достаточно простого рисунка на листе бумаги. Это часто экономит массу времени и сил, потому что заказчик редко осознает, что он хочет, пока не изобразит это.
Организация тестирования
После разработки и тестирования вами, следует убедиться, что пользователи также провели тесты и подтвердили работоспособность системы. Для этой цели в идеале хорошо составить тест-план: набор действий пользователя с указанием результата, который мы ожидаем получить.
Сдавая очередной этап работ обязательно письменно напомните пользователю о необходимости всё протестировать.
Очень сложно будет заставить пользователя не то что составить план, а даже просто протестировать часто используемые функции. Тем не менее, вы всегда должны напоминать пользователю о необходимости тестирования. Так вы реже будете оказываться крайним в случае обнаружения дефекта логики или ошибок в данных.
Инструкция
Включите в оценку составление инструкции. Вам необходимо сделать этот документ это будет описание всех действий в системе, сопровождаемое иллюстрациями.
Инструкция в простом случае займет у вас 3-4 часа работы, её мало кто будет читать, вы уже вряд ли будете обновлять её позже, но она обязательно должна быть.
Вам это пригодится на будущее вы сможете показывать наглядные материалы и примеры ваших работ, даже если не сможете показать сами приложения из-за ограничений интеллектуальной собственности, например.
Инструкцию необходимо делать непосредственно перед началом работы пользователей в готовой системе, потому что на начальном этапе, в первые дни разработки, всё очень быстро меняется и вы не сможете её постоянно переписывать.
Поддержка
Формат и объем поддержки следует обговорить на этапе первичных переговоров. Вы можете оказывать 3 вида поддержки: консультирование, доработки, устранение неисправностей и сбоев.
Разумеется, если вас раз в год просят просто помочь поправить номер счета в форме договора сделайте это бесплатно. Это не займет много времени, не требует сосредоточенности, в то же время может принести вам новые заказы в будущем ваши контакты всегда под рукой у заказчика.
Важные моменты поддержки:
-
Время вашего отклика на запрос, в зависимости от критичности запроса
-
Критерии оценки критичности инцидентов (используется редко)
-
Максимальное количество часов работы в месяц
-
Максимальный объем доработок
-
Схема и размер оплаты абонентская плата + работа с инцидентами и запросами
Крупные клиенты нуждаются в ежемесячной поддержке и готовы платить за неё сумму от 3 до 10 тысяч рублей, обращаясь от 2 до 10 раз с запросами, требующими от 5 минут до 1 часа вашего времени. В этом случае вам выгодно оговорить абонентскую плату и срок ответа.
Это повторяющиеся платежи, доля которых должна быть как можно больше.
Получение отзывов
Не постесняйтесь просить отзыв о вашей работе у заказчика проведите с ним небольшую беседу, выяснив, насколько вы попали в его ожидания. Затем вы можете сами точно изложить услышанное, согласовать результат с заказчиком и добавить к себе в портфолио.
Если в ходе проекта что-то шло не так, то вы тоже узнаете об этом таким образом.
Вот те 15 тезисов, которые мы вынесли из многочисленных ретроспектив. Наша специфика всякие конструкторы и low-code, поэтому некоторые моменты покажутся спорными, но основную суть это не сильно меняет. Спасибо!
