Привет, vc! Я Дмитрий Цапля, СЕО along — студии продуктовой разработки из Иннополиса. В этой статье я расскажу о трёх важных моментах, о которых стоит договориться на берегу с разрабом/студией. Эти правила сохранили нашим клиентам деньги, а нам — нервы.
Простои
Представим, что вы работаете с разработчиком/студией/подрядчиком по формату Т&M (в предыдущей статье я писал о плюсах и минусах этого формата). В этом формате исполнитель получает оплату за потраченные на проект часы.
Если студия нанимает разработчиков в штат, то она платит им фиксированную з/п в месяц. Другими словами, компания выкупает ~160 рабочих часов в месяц у человека и пытается их продать.
Если компания не продала часть часов, то она потеряла деньги. Это заставляет компанию торопить разработку или устанавливать минимальный лимит по часам.
На придумывание и тестирование фич требуется время, которого у вас в таком формате работы не будет. Каждый день задержки создает напряженность между вами и подрядчиком.
Если у вас нет огромных бюджетов на продукт, то платите разработчикам за часы работы. Договоритесь о том, кто будет платить за простои и как вы будете решать связанные с этим проблемы
Вовлеченность
Треть наших клиентов отказалась от предыдущей команды из-за низкой вовлеченности. И нет, вовлеченность это не про овертаймы по выходным и не про «быть на связи 24/7».
Вовлеченность — это желание и умение разработчиков думать о смысле того, что они делают. Заказчик далеко не всегда принимает правильные продуктовые решения. Ищите разработчиков, которые будут с вами спорить и доказывать вам, что вы неправы.
Такие разработчики могут стоить дороже, с ними бывает сложнее работать, но это того стоит. Ищите студии, которые выделяют вам менеджера, который может управлять продуктом, а не только проектом. Привлеките в проект системного аналитика, если есть такая возможность.
Обсудите уровень вовлеченности на берегу: будут ли разработчики с вами спорить, или же просто работать по вашему ТЗ?
Нет микроменедждменту!
Микроменеджмент — стиль управления, который подразумевает контроль каждого шага исполнителя. Микроменеджмент от заказчика появляется из-за отсутствия доверия и создает токсичную атмосферу. Для того, чтобы у вас не было желания микроменежить, создайте прозрачные и удобные инструменты управления проектом.
- Продуктовые требования советую собирать в гугл документах и прорабатывать предложения через гугл комментарии — так они не потеряются.
- Комментарии по дизайну/UX/анимациям можно оставлять в виде комментариев в figma — по аналогии с гугл документами.
- Попросите разработчиков настроить автоматический пайплайн публикации приложения в TestFlight (для iOS) или генерации apk (для android). Мы получаем фидбэк от клиента при каждом новом релизе. Заказчик смотрит результат нашей работы в любое время и в любом месте.
- Если вы работаете по часам, то создайте прозрачный процесс отчетности. Попросите разработчиков использовать трекеры и собирать отчеты в часах в одном месте. Мы используем Clockify (Toggle тоже отличный вариант). Вам не придется каждый раз спрашивать менеджера проекта о том, “сколько мы потратили денег”.
При этом старайтесь доверять вашей команде и не надоедать постоянными вопросами в духе “почему эта задача заняла 5 часов, хотя мы планировали 4”? О доверии я писал в первой части этой статьи.
О чём стоит договориться?
Договоритесь о том, кто будет платить за простои. Готовы ли вы платить за них?
Договоритесь об уровне вовлеченности. Готовы ли вы дать разработчикам свободу принимать решения?
- Договоритесь о прозрачных процессах, чтобы вам не пришлось микроменеджить. Готовы ли вы доверять разработчикам?
Ждём вас в нашем тг-канал @alongpw — мы пишем про создание стартапов, разработку и управление проектами.
Если договорённости будут только на словах, то грош цена таким договорённостям. Рано или поздно, так или иначе их начнут нарушать и, скорее всего, в оскорбительной манере, чтобы купировать собственное чувство вины от нарушения.
В договоре можно указать сторону, которая платит за простои и форму отчетности, но...
В договоре не получится прописать уровень вовлеченности и приятный опыт взаимодействия. Об этом нужно договариваться устно, а если ожидания не соответствуют реальности, то искать другую команду
Для того, чтобы это было возможно, не нужно сразу подписывать долгосрочные контракты. Также обязательно установите требования к кодстайлу, хорошей архитектуре и выбирайте студии с популярным стеком. Тогда проблем при смене команды будет меньше
С чего бы? Описать средства коммуникации можно. Можно даже записывать все встречи, чтобы исключить голословные утверждения/обещания. Вот только возникло ощущение, что большинство команд, увидев такой договор, быстро намажет жиром пятки, т.к. ни одна команда не может гарантировать результат при отстуствии предельно подробного технического задания, исключающего любые доработки в процессе выполнения. А значит, что обе стороны будут лукавить и при заключении соглашения, и при возникающих простоях и доработках.
И вот начинаются задержки, недооценки задач, путаница в состояниях и, внезапно, "забывчивость" заинтересованных лиц.
Так и не нужно бежать от доработок и делать подробное ТЗ. Ни один человек в мире не может сделать ТЗ, которое бы гарантировало отсутствие необходимости правок и доработок вне ТЗ
Нужно быть гибким и работать по ТМ . В agile есть понятие "конус неопределенности", я писал про это в предыдущем посте. Оценка всё равно никогда не будет точной, и заказчик никогда не попадёт в оценку (если конечно оценка не специально умножена на 4). С бэклогом нужно уметь работать, менять приоритеты и отказываться от фичей (или менять их)
При этом ты не можешь гарантировать договором то, что сотрудники студии будут приятными в общении, и что они будут давать хорошие предложения по продукту. Это можно определить только на практике
Вы описываете методы реализации "вовлеченного" подхода. Можно документировать все встречи, писать агенды и тд, но если при этом не вкладывать в них смысла и желания дать пользу клиенту, то получается пустая бюрократия, которая будет скрывать реальную проблему.
Конечно, без ТЗ результат ХЗ, но писать подробные требования к тому, чего в природе ни в каком виде не существует очень сложно. В этом и есть суть стартапов, что в начале не знаешь то, что получится в конце. В статье не говорится про сложный Энтерпрайз, или конкретный продукт для бизнеса, там все совсем по другому)
Я не говорю, что требования не нужно писать. Я говорю о том, что нет смысла вписывать ТЗ в контракт и плясать потом вокруг него с бубном.
Энтерпрайз и продукт для бизнеса тут тоже ничем не отличается. Чем больше бюрократии и меньше гибкости, тем хуже и дороже получится результат
Полностью согласна с вашими словами, потом еще начнется "а так мы не договаривались". По личному опыту скажу, всегда нужно составлять договор с подробно описанными пунктами
«А мы так не договаривались» начинается, когда вы об этом действительно не договаривались, и каждый подумал, что будет так, как ему кажется
Поэтому я и советую всё проговорить перед началом. Это можно отразить в договоре, хотя не о всех вещах возможно договориться
Еще важно закрепить ответственных, которые будут чемпионить какие-то области. А то простои договорились кто оплачивает, а кто будет всю эту котовасию заводить и заставлять двигаться - нет))
Иногда подвисает какой-то простой вопрос, а из-за отсутствия ответственного никто не двигает процесс вперед, все ждут, что придет "папа" и все разрулит.
А еще можно работать через корпоративный мессенджер или бизнес трекер, приглашая к себе на сервер сотрудников. Так информация точно не потеряется, потому что будет всегда храниться у Вас.
Так же удобнее работать с задачами для сотрудников, ведь можно настроить под каждый тип групп свою задачу, а потом отслеживать ее выполнение без постоянных вопросов по прогрессу.
А еще Вы сможете всегда держать коммуникацию с сотрудниками, например у нас для этого разрабатывается WEB версия, с помощью которой любой человек без установки приложения на устройство (iOS/Android/PC) сможет подключиться к чату :)
Кстати, так и не понял сколько стоит ваш сервис) Для меня это очень важно, потому что по 8 баксов в месяц за сотрудника за слак было дорого платить, поэтому есть опенсорсный рокет чат (который просит деньги за пуш-уведомления кстати)
Это потому, что мы пока в разработке. По той же причине не предлагаем тестить Web. Зарелизимся в этом году, монетизацию распишем позже, но пока ориентируемся на $3-4 за сотрудника, если речь о полной версии. Все зависит от курса в будущем, конечно :) Плюс бесплатный тестовый период, разумеется.
А на чём вы кстати пишете приложение? Мне было бы интересно с вами побольше пообщаться, если интересно то предлагаю в тг списаться (@dimtsaplia)
Да, напишем сейчас, можем пообщаться
Мы пока так и не нашли решения, которое бы нас устраивало. Используем rocket chat как менссенджер, дискорд для звонков, гугл доки и ноушн для гайдов, ютрек как доску и клокифай для трекинга часов
Space от JetBarains - классное решение, но всё еще слишком сырое. Без мобильных приложений и десктопа особо нет пользы от корпоративного мессенджера
Кстати, посмотрел ваш продукт - как будто обрезанная версия tada team или что-то вроде того
Я бы на вашем месте сделал лучше побольше интеграций в существующие мессенджеры для создания задач из сообщений в любых мессенджерах и в любых досках. Хотя вроде уже где-то видел такое в виде бота для тг и слака.
Мы рассматриваем интеграции для переноса к нам в чат переписки и файлов из других мессенджеров. А задачи наверняка можно создавать ботами и в тг. Но у тг много минусов для работы помимо отсутствия задач. При всех его бешеных плюсах. Плюс сейчас подготовили в бэклог фичу хранения данных, чтобы в каждом отдельном чате (или задаче) было свое хранилище информации с настраиваемыми доступами. Возможно, конфлюенс не всем станет нужен. Наши коллеги из тада - проделали огромную работу, но нам их продукт видится перегруженным. Возможно он актуален для энтерпрайза, но мы в него не целим. Наша ЦА - это МСБ.
Для меня кажется важным еще треды (как в слаке) - чтобы можно было под сообщением общаться. Вы планируете это добавить?
У нас это сейчас реализовано через бесконечную вложенность чатов. То есть сообщение какое-то, его можно превратить в задачу и общаться внутри него. Соответственно, общий чат останется без флуда
Супер, это важная фича для нас, мы тада не купили только из-за того что у них нет тредов
А если я не хочу создавать задачу, а хочу просто обсудить какую-то тему с коллегами?
Мы называем это активность. Активность по сути - чат. Она может быть просто тредом (как в вашем примере), может быть задачей (можно указать сроки, напоминалки и т.д.), может быть проектом с дедлайном, может быть командой.
А вы для IT делаете или в целом для МСБ?
В целом для МСБ, какому-то сетевому магазину тоже получится пересадить своих сотрудников и вести все коммуникации в нашем решении