15 заповедей IT-фриланса и мелкой разработки
Самая сложная часть — это удержать заказчика, когда он сделал первый пробный шаг в сотрудничестве с вами, но ещё не привязан к вам сколько-нибудь серьезно. Я расскажу о наиболее частых ошибках и удачных моделях поведения в работе с клиентом. Это опыт наших разработчиков, вынесенный из множества мелких и средних проектов.
Рассмотрены, в основном, сугубо технические моменты, никакой техники продаж и прочего маркетинга.
Некоторые вещи могут показаться очевидными, но для неопытного разработчика могут стать если не открытием, то хорошей подсказкой в нужный момент. По признанию приглашенных спикеров, даже опытные разработчики, бывает, упускают возможности, совершая стандартные ошибки из года в год. По отзывам студентов с курса мы подумали выложить материал здесь в виде тезисов.
Аналитический разрыв
Заказчик подразумевает, что вы знаете очевидные для него вещи, о которых он умолчит, но будет много рассказывать вам про несущественные детали. Вам нужно максимально прояснить для себя важные для вас тонкости его бизнеса: уловить суть процесса.
Первый контакт
Вы не можете быть экспертом в бизнесе заказчика, можете не знать его технологии и системы, с которыми нужно будет интегрироваться. Тем не менее, вы должны описать заказчику предстоящий проект так, чтобы он поверил в его осуществимость.
Вы должны выглядеть профессионально. Это несложно сделать.
После краткого описания задачи заказчиком вы принимаете решение. Если проект понятен и может быть решен вашими силами, то есть, например, там нет требования написать драйвер на С++ или разработать математическую модель на незнакомом вам языке, то вы двигаетесь дальше. Иначе вы расстаетесь — не беритесь за то, что не можете оценить.
Если перед вами реализуемый проект, то вы описываете как вы его будете делать:
Вы возьмете день-два на подготовку состава решения — это рамки проекта
По составу решения сделаете оценку проекта в днях и деньгах
Возможно, вы предоставите первый прототип вместе с составом решения
Составите план проекта — очень простой документ
Обговорите вопрос о собственности на разработку — задайте такой вопрос
Напишете для пользователей инструкцию по продукту
Договоритесь о гарантийном сроке и формате технической поддержки
Получив четкое видение проекта, заказчик будет больше доверять вам как разработчику. Многие вопросы и сомнения в вашем опыте и способности сделать работу отпадут сами.
Состав решения
После первой встречи с вы фиксируете краткое описание задачи и перечисляете объекты и процессы, которые будут созданы в рамках проекта.
Рекомендуем делать совсем простой документ, он не является техническим заданием (ТЗ), но фиксирует основные моменты, которые обсуждались на встрече с заказчиком.
Фрагмент документа, ограничивающего рамки проектаУчасток, процесс или модуль системы | Решаемая задача / функционал системы |
Система в целом | В системе будут реализованы: |
Номенклатура | Будет использоваться единый справочник номенклатуры для синхронизации 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, поэтому некоторые моменты покажутся спорными, но основную суть это не сильно меняет. Спасибо!
