Всем привет, меня зовут Константин Кузнецов, я генеральный директор и основатель компании RocketSales. В IT-сфере довольно часто встречается история, когда отдел разработки живет в своей вселенной. В этой вселенной есть увлажнители воздуха на каждом рабочем столе, куча гаджетов и клинеров для мониторов и клавиатур и, скорее всего, своя система управления задачами и проектами.

Что в этом такого?

Возможно, для кого-то ничего. Но мы столкнулись с проблемой. Мы занимаемся построением и автоматизацией систем продаж, внедряем CRM, создаем облачную инфраструктуру для бизнеса. В клиентские проекты помимо отделов разработки и производства часто включаются маркетологи, продавцы, бухгалтер, другие сотрудники. И мы стали думать, как организовать эффективный процесс управления проектами.

Если процесс разработки и производства организован в платформе типа Jira или GitLab, то никто, кроме разработки, не понимает, что там к чему. Чтобы подключить к проекту стороннего сотрудника, с ним нужно встретиться, объяснить контекст, где-то зафиксировать задачу, потом контролировать степень готовности в рабочих чатах, через чат же получить результат, внести в Jira. И так каждый раз.

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

Пару лет назад мы открыли для себя платформу Asana. В этом материале я хочу рассказать, как мы организовали процесс управления разработкой и производством, чтобы:

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

Немного о знакомстве с Asana

На поиск удобного софта для проектного управления я потратил 10 лет. Trello, Jira, Планфикс, Мегаплан, Битрикс24 и десятки других таск-трекеров не прошли тест на прочность. Потом я нашел Asana. И все сложилось.

На наш взгляд, это лучшая и самая быстро развивающаяся платформа для управления задачами и проектами. Сегодня Asana является мировым лидером по популярности и удовлетворенности пользователей. Об этом говорит график рейтинга g2.



Мы фанаты Asana, даже прошли сертификацию, чтобы иметь возможность внедрять ее клиентам.

Коротко опишу процесс от продажи до реализации проекта

Так как мы продаем IT-услуги, воронка у нас довольно длинная и, ближе к концу, она заходит в отдел производства и, иногда, разработки.

Отдел продаж проводит стандартные манипуляции: аудит, согласование КП, подписание договора, передача сделки в производство. Производство может не принять договор: в нем обязательно должны быть указаны бюджет, дата передачи в производство, расчетный фонд времени на реализацию проекта.

Благодаря связке amoCRM + Asana, при передаче сделки из отдела продаж в производство и обратно, работа нигде не прерывается. Голубым цветом обозначена зона ответственности отдела продаж, оранжевым отдела производства, розовым отдела разработки.



Важно, что отдел разработки, в отличие от проектного отдела, участвует не в каждому проекте. Иногда настройка системы не требует кастомных решений.

Итак, когда руководитель принял проект в производство, менеджер по продажам в 1 клик переходит в Asana (скриншот). Из amoCRM проект автоматически создаётся в Asana.



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



Менеджер может запустить в задаче любой из предложенных автоматических бизнес-процессов:

1. Найти/Создать проект Клиента + Прикрепить туда задачу
2. Заполнить задачу информацией по сделке
3. Создать сделку из текущей задачи

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

Эта доска помогает принимать новые проекты в работу. Но контролировать на ней актуальные статусы и наличие проектов в зоне риска неудобно.

Как мы группируем задачи и проекты клиентов

Из общей доски всех проектов менеджер добавляет проект еще на 3 доски:

1. персональная доска клиента;
2. портфель активных клиентов;
3. портфель менеджера.

Разберемся, для чего нам каждая из сущностей.

На скриншоте вы видите персональную доску клиента.



Зачем эта доска?

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

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

Что есть на этой доске?

Наша Asana связана с несколькими сервисами:

• CRM-система (для взаимодействия с отделом продаж),
• TimeDoctor (для учета времени),
• ERP-система (для агрегации всех данных в едином интерфейсе).

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



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

Что дает использование доски?

В итоге в ERP-системе мы видим Отчет по проектам. Статус сделки, участники проекта, бюджет на проект, количество отработанных часов и сроки.



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

Портфели Asana

Эта функциональность реализована в Asana уже давно. Но мы не сразу ее оценили. Сперва мы просто собрали в портфели все проекты наших менеджеров. Оказалось, что за время работы в компании Денис Киселев поработал с 61 клиентом.

Знать это прикольно, но недостаточно, чтобы оправдывать потраченное на сбор время. И мы забили на портфели. Все поменялось, когда мы приравняли проект в Asana к одной сделке в CRM-системе.

Раньше руководитель подписывался на все проекты и получал уведомления по всем изменениям в Inbox (ленту уведомлений). Каждое обновление статуса, новый комментарий отображались в ленте, начиная с самого нового. В понедельник руководитель садился и выполнял задачи из инбокса последовательно. О приоритетах речи не шло, до важных задач порой не доходили руки.

Теперь есть портфель сотрудника и портфель проектного отдела. В первом менеджер управляет своими проектами, второй дает руководителю контролирующий функционал по текущей загруженности всех сотрудников.

Портфель проектного отдела

На скриншоте вы видите отсортированные по сотрудникам проекты.



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

Руководитель быстро может оценить:

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

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

Портфель сотрудника

Собственный портфель есть даже у руководителя проектного отдела. Если, тьфу-тьфу-тьфу, он снимет с себя полномочия, новый человек увидит все подконтрольные проекты, которые он должен продолжать отслеживать.

Линейные сотрудники также оценили удобство планирования нагрузки в портфеле. В табе Нагрузка Asana анализирует объем задач с учетом дедлайнов и предупреждает, если сотрудник запланировал неподъемный объем задач. Менять дедлайны и корректировать детали можно не уходя из этой вкладки.

Решение багов и кастомная разработка

Отдельная команда отвечает у нас за разработку. К ней в рамках бизнес-процесса поступают задачи двух типов:

1. баг,
2. новая разработка.

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

Процесс разработки, в целом, выглядит так.



Задачи падают на доску разработки в Asana. Вот она.



Постановщик задачи выбирает тип Баг или Фича, устанавливает степень критичности, указывает заказчика, внутренние отделы компании, которые затрагивает задача. Когда задача соответствует всем требованиям внутреннего регламента, постановщик нажимает на значок молнии в верхней панели над задачей и запускает автоматический бизнес-процесс Оценить в разработке.



Руководитель отдела разработки получает уведомление о новой задаче на оценку, сама задача на время оценки перемещается на отдельную одноименную доску.

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

• на личной доске проектного менеджера,
• на доске техподдержки,
• на доске разработки.

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

Что получилось, когда мы вернули отделы разработки и производства в единую среду с командой?

Во-первых, клиентские проекты стали более долгосрочными. За счет постоянно пополняемого бэклога вырос средний чек.

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

В-третьих, и сотрудники, и руководители, и клиенты получили полную прозрачность в запланированных и выполненных задачах. Мы научились УПРАВЛЯТЬ проектами, осознали, что это абсолютно технический процесс, из которого можно почти полностью исключить человеческий фактор.

В-четвертых, команда стала более сплоченной. Раньше сотрудники слабо представляли, чем занимаются мифические отделы разработки и производства.

Сейчас, видя процесс разработки и технической настройки систем:

• отдел продаж находит в нем идеи и вдохновение, как продавать,
• маркетологи регулярно берут полезный контент для постов, статей, позиционирования и рекламных текстов,
• руководители анализируют потребности и поведение клиентов, корректируя стратегию.

Получилась win-win-win трансформация, в которой выиграли и мы, и клиенты, и наши партнеры. Буду рад, если вы поделитесь мнением в комментариях: было ли что-то полезное в моей статье и какие методы управления проектами вы используете в разработке!

Если вы запускаете какой-то сервис в интернете, всегда есть соблазн предложить бесплатный тариф, чтобы завлечь публику.

Вы думаете, что людям понравится и они захотят перейти на нормальный тариф с полными функциями. Это большая ошибка. Если человека полностью устраивает бесплатный тариф, то он на нём останется навсегда!

И будет требовать от вас надёжного сервиса, новых функций и предъявлять претензии. Чем меньше платит пользователь тем больше шуму он поднимает в социальных сетях и тем больше поддержки требует. Отрицательные отзывы идут именно от бесплатных юзеров, а не от платных (это вполне логично, если подумать).

Британский разработчик Гвидо Зюйдхоф (Guido Zuidhof) настолько устал от таких пользователей, что запустил специальный сайт No Free Plan, на котором излил всю свою боль по этому поводу.

Основной аргумент Гвидо заключается в том, что бесплатные пользователи дорого обходятся.

Цена бесплатного плана

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

Но в реальности у каждого бесплатного плана есть конкретная цена. Она измеряется в вашем времени и усилиях.

Мы уже упомянули, что люди на самых дешёвых тарифах самые назойливые. Как думаете, от кого придёт больше запросов в службу поддержки: от десяти крупных корпоративных клиентов с подпиской за $100 в месяц или от тысячи пользователей, каждый из которых сидит на тарифе за $1 (включая школьников, студентов)? Очевидно, что в первой группе более высококвалифицированные специалисты и профессиональные IT-департаменты, которые задают меньше глупых вопросов.

Хотя по деньгам это абсолютно одинаковая сумма, но во втором случае седина покроет ваши виски гораздо быстрее, уверен Гвидо Зюйдхоф.

Поэтому он предлагает самый эффективный, хотя и контринтуитивный выход из положения повысить цены.

От бесплатных пользователей действительно бывает много шуму. Например, они могут требовать у разработчика включить в бесплатную версию какие-то функции из платных тарифов. А если разработчик отказывается, могут возмущаться, писать негативные отзывы о продукте и так далее. Это действительно вредит бизнесу.

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

В итоге бесплатные тарифы слишком дорого обходятся.

Ничего бесплатного не бывает

Понятно, откуда идёт заблуждение об эффективности бесплатных планов. Мы видим, что крупнейшие интернет-компании Google и Facebook не берут никакой платы за основной набор услуг. Хотя у Google есть много платных сервисов, но для широкой публики всё основное бесплатно. И на Google Drive, и на Gmail есть бесплатный лимит, который устраивает почти всех.

И стартап YouTube тоже никогда не брал платы за просмотр видеороликов.

Но важно понимать, что эти компании являются исключением из правила! По модели фримиум работать очень тяжело, и мало у кого получается без мощной накачки инвестициями. Все риски нужно тщательно просчитать.


Сервис слежки за сотрудниками Hubstaff почти обанкротился с таким бесплатным тарифом

Прежде чем предлагать бесплатный сервис налево и направо, наращивая пользовательскую базу в геометрической прогрессии, нужно продумать бизнес-модель. Это проблема не только SaaS, но и онлайновых СМИ, которые хотят сохранить бесплатную подписку. Например, несколько лет назад закрылся Gigaom популярный и качественный сайт с техническими новостями и аналитикой. Один из лучших представителей IT-журналистики не смог выжить по модели фримиум.

Какие альтернативы?

Пробный период

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

К тому же, здесь работает искажение сделанного выбора тенденция задним числом приписывать положительные качества предмету или действию, которые человек выбрал. То есть главное заставить человека согласиться на бесплатный триал и объяснить, что выбор всегда можно отменить ну а дальше в силу вступает это когнитивное искажение. Главный трюк пробных периодов.

Пробный период эффективен даже без тёмных паттернов. Лимит можно выставить по времени (30 суток) или по объёму услуг (в гигабайтах трафика, минутах просмотра и т. д.).

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

Фильтрация пользователей

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

Вы выбираете действительно достойных, кто вам нравится.

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

Здесь нет никакого снобизма, разработчик сервиса имеет полное право на такую избирательность, какую захочет.

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

Ещё один вариант фильтрации заранее брать данные платёжной карты с выставлением счёта, если пользователь вышел за пределы бесплатного лимита, по образцу Google Cloud. Таким образом, отсекается часть юзеров, которые принципиально никогда не готовы ни за что платить, и работает страховка от чрезмерного использования сервиса.

Единовременный платёж

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

Например, это может быть чисто символический платёж в 1 доллар а затем тот же бесплатный тарифный план навсегда. Или ограниченный набор услуг, как в бесплатном плане, но за минимальную сумму.

Это не полноценная подписка на сервис, а некий промежуточный вариант между вечным пробным периодом и нормальной платной подпиской. По аналогии с фримиум (freemium) его можно назвать чипиум (cheapium).

Важно точно обговорить условия такой подписки. Очевидно, что в наше время никто не может гарантировать вечный сервис. Поэтому нужно установить минимальный срок работы сервиса (хотя бы 1-6 месяцев), а если тот закроется раньше, то деньги будут возвращены. Рекомендуется указать возможность закрытия аккаунта в случае неактивности (в течение полугода или больше), а также различные льготы подписчикам.

Автор концепции No Free Plan говорит, что на создание сайта его побудило чтение многочисленных дискуссий в сообществе Indie Hackers, где общаются основатели мелких онлайн-компаний и независимых бизнесов. Обычно это разработчики-одиночки, которые запускают платный сервис, SaaS, утилиту, игру или мобильное приложение или несколько таких сервисов, зарабатывая доход в качестве индивидуального предпринимателя.

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

Проблема опенсорсных мейнтейнеров

Эта проблема отлична известна в сообществе Open Source. Мейнтейнеры опенсорсных проектов работают бесплатно и быстро выгорают на этой работе, сталкиваясь с массой претензий от недовольных пользователей.

Не каждый выдерживает такое давление. Некоторые психуют и просто удаляют свои репозитории, как это сделал хабраюзер fafhrd91, автор веб-сервера Actix Web. После критики его профессиональных навыков автор отказался от дальнейшей поддержки проекта (репозиторий всё-таки восстановили и передали другому мейнтейнеру).

От работы больше никакой радости. Возможно, вы захотите уйти, но не сможете из-за чувства ответственности за свой код, сообщество и людей, которые используют ваше программное обеспечение, пишет мейнтейнер GNOME Calendar. К сожалению, работа мейнтейнером свободного ПО может плохо отразиться на вашем психологическом и эмоциональном здоровье.

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

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

Преимущества бесплатных тарифов

Конечно, его мнение крайне субъективное. Сам Гвидо запустил два простеньких инди-сервиса и на сегодняшний день не заработал ещё тысячи долларов. То есть у него пока не накопилось достаточно опыта, чтобы делать такие выводы и объективно оценить пользу бесплатных тарифов.

В то же время мы видим, что многие компании предлагают данный вариант. Бесплатные вечные тарифы есть у Trello, Jira, Slack, Asana, Dropbox. Миллионы профессионалов используют эти сервисы бесплатно, а потом рекомендуют их в компаниях, куда приходят работать и те покупают платную подписку. Ссылки на Dropbox разлетаются по интернету как вирусный маркетинг. Таким образом, здесь расходы на бесплатные тарифы многократно окупаются.

Вопрос только в том, это стандарт индустрии или исключение из правил?

Модель действительно работает в интернет-стартапах, у которых главная цель максимально быстро нарастить аудиторию, пусть и себе в убыток (инвесторы оплатят расходы). Эти убытки окупятся в будущем. А мы как обычные пользователи с удовольствием наслаждаемся бесплатным сервисом отличного качества, без рекламы.

Это модель будущих единорогов.

Но правда и в том, что бесплатный план не всегда конвертируется в продажи. Если по неосторожности выложить в бесплатный тариф что-то полезное, то вы рискуете попасть на деньги, когда налетят миллионы юзеров из Юго-Восточной Азии. Тогда 95% вашего трафика будут генерировать бесплатные пользователи, которые никогда не заплатят ни цента, а скорее найдут другую бесплатную альтернативу.

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

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

---

На правах рекламы

Наша компания предлагает аренду VPS для совершенно любых проектов. Создайте собственный тарифный план в пару кликов, максимальная конфигурация позволит разместить практически любой проект 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe!