Как стать автором
Обновить

15 заповедей IT-фриланса и мелкой разработки

Время на прочтение 10 мин
Количество просмотров 13K

Самая сложная часть – это удержать заказчика, когда он сделал первый пробный шаг в сотрудничестве с вами, но ещё не привязан к вам сколько-нибудь серьезно. Я расскажу о наиболее частых ошибках и удачных моделях поведения в работе с клиентом. Это опыт наших разработчиков, вынесенный из множества мелких и средних проектов.

Рассмотрены, в основном, сугубо технические моменты, никакой техники продаж и прочего маркетинга.

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

Аналитический разрыв

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

Первый контакт

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

Вы должны выглядеть профессионально. Это несложно сделать.

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

Если перед вами реализуемый проект, то вы описываете как вы его будете делать:

  1. Вы возьмете день-два на подготовку состава решения – это рамки проекта

  2. По составу решения сделаете оценку проекта в днях и деньгах

  3. Возможно, вы предоставите первый прототип вместе с составом решения

  4. Составите план проекта – очень простой документ

  5. Обговорите вопрос о собственности на разработку – задайте такой вопрос

  6. Напишете для пользователей инструкцию по продукту

  7. Договоритесь о гарантийном сроке и формате технической поддержки

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

Состав решения

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

Рекомендуем делать совсем простой документ, он не является техническим заданием (ТЗ), но фиксирует основные моменты, которые обсуждались на встрече с заказчиком.

Фрагмент документа, ограничивающего рамки проекта

Участок, процесс или модуль системы

Решаемая задача / функционал системы

Система в целом

В системе будут реализованы:
- все необходимые справочники (словари)
- система авторизации пользователей (имя/пароль) и ролевая модель доступа пользователей
- средство быстрой навигации среди всех связанных объектов
- на всех этапах прохождения объектов учета хранится информация об их истории: поставка, перемещение, изменения статуса, расход
- рабочие места имеют базовый дизайн Платформы и обеспечивают минимальное количество «кликов» (простоту) при выполнении операций
- система сопровождается инструкцией пользователя
- управление и контроль в системе осуществляются с помощью рабочих мест в виде планшета, смартфона или компьютера с монитором, подключенных к сети Интернет

Номенклатура

Будет использоваться единый справочник номенклатуры для синхронизации 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, поэтому некоторые моменты покажутся спорными, но основную суть это не сильно меняет. Спасибо!

Теги:
Хабы:
+23
Комментарии 19
Комментарии Комментарии 19

Публикации

Истории

Работа

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн