Хочу поведать свою историю, как большая нагрузка, множество рутинной работы и постоянное отвлечение меня от основной работы, разработки архитектуры софта, толкнули меня на создание системы, которая бы автоматизировала ряд процессов в пресейле новых проектов. Что позволило мне сэкономить в итоге много времени и сил.
Скажу пару слов о том, чем я занимаюсь. Более 25 лет я занимаюсь разработкой программных продуктов под WEB. Начинал еще в 90х, как разработчик десктопных приложений. Писал, практически на всем. На разных ЯП, CMS, фреймворках. Перепробовал все что только можно. Искал себя и смысл жизни (себя нашел, а смысл жизни - нет). Меня всегда увлекала инженерная и архитектурная часть, поэтому я хотел докопаться до самой сути вещей, уделяя огромное внимание не технологиям и инновациям, а деталям, логике и здравому смыслу. Лет через 10 после старта, я устал от однотипных задач и непонимания, что я делаю и зачем, не имея возможности влиять на конечный продукт. И ушел в архитектуру.
Но к большому сожалению, чудеса бывают только в сказках. Поэтому компании (это, как правило, был либо украинский аутсорс ��а Запад, либо Западный продукт по прямому контракту) нагружали меня дополнительно всем чем только можно. Мол ты же не разрабатываешь архитектуру по 8 часов в день каждый день, так что будь: тим лидом/тех лидом, системным аналитиком, помоги с кодом той или иной команде, поработай DevOps и самое противное - это, к нам зашел новый клиент на пресейл, поэтому нужно очень быстро оценить объем работы, расписать и заэстимейтить фичи с тасочками (извиняюсь за американизмы, все работа ведется только на английском языке).
Вот пресейлы я реально не люблю, так как для того, чтобы объективно оценить проект, нужно создать под него архитектуру. А за архитектуру на этапе дискавери (исследования бизнес требований) никто не хочет платить. Но очень часто бывает так, что в компании вообще нет таких людей, как солюшен архитекторы или системные архитекторы. И тогда пресейл менеджеры бегут к разработчикам и начинают их мучить, чтобы те быстро сделали эстимейты, желательно на вчера. Про чувства программистов писать не буду, уверен вы и так это знаете.
В итоге рождаются для клиента такие чудесные коммерческие предложения в Excel таблицах, как "Форма регистрации на сайте: 40 - 120 часов, $1600 - $4800". Вы можете это даже в Гугл поиске найти, на англоязычных сайтах. Это реальный пример из жизни. На уточняющий вопрос заказчика, что это вообще значит, менеджеры просто пожимают плечами, а клиент идет дальше искать "надежду" и здравомыслие в других компаниях.
Вот на пресейлах я и остановлюсь подробнее и расскажу всю боль, и как я решил ее уменьшить. Стоимость создания IT продукта напрямую зависит от времени, затраченного на его создание. А время уже в итоге умножается на рейт компании ($40 - $80), что дает в результате стоимость в деньгах. Поэтому, сосредоточимся на том, как правильно оценить временные затраты. Самый точный метод — это декомпозиция функционала на самые маленькие элементы, которые уже можно достаточно просто оценить. Как это сделать правильно?
Первое, что нужно сделать, — это собрать все бизнес-требования клиента и проанализировать их. Залог успеха и правильной оценки заключается в том, чтобы полностью прояснить для себя весь проект. Какова его цель, какие функции должны в нем быть, почему клиент видит реализацию своих идей именно так и т.д. Для того чтобы собрать все это в своей голове, необходимо создать бизнес-диаграмму (workflow), на которой графически изобразить весь функционал, связи между этим функционалом и все алгоритмы действий, которые должны работать в проекте. Этот воркфлоу нужно делать на высшем уровне, без углубления в детали. Это поможет сразу выделить очевидные места, которые можно относительно легко оценить. Например, система регистрации и авторизации, форма обратной связи и т.д. Для более сложных частей проекта придется делать более глубокую декомпозицию, разбивая все на отдельные функции, а функции — на более мелкие задачи.
С помощью такого подхода можно будет получить подробную документацию с множеством мелких задач, которые уже можно более или менее точно оценить, дав минимальную и максимальную временную оценку. В таком подходе есть как плюсы, так и минусы.
Главные плюсы — это максимально точная оценка и подробная проектная документация. Минус — большие временные затраты на оценку всех задач, и как следствие - большая стоимость затрат на дискавери сессию, которая может быть не оплачена. А также необходимо наличие специалистов с соответствующей квалификацией.
Есть еще ряд трудностей, с которыми сталкиваются разработчики при оценке проекта. Это сохранение и переиспользование оцененных ранее задач. Использование для расчетов Excel или других таблиц, что неудобно для работы и выглядит не слишком серьезно в глазах клиента. Плюс невозможность затем превратить полученный документ в реальный проект, например, в системе управления проектами Jira, Trello или другой. Также непонятно, где хранить наработки в виде диаграмм, схем и другой документации, созданной для задачи.
Иногда я встречал, что компании заводят новый проект на пресейл в систему прожект менеджмента, например в Jira. Делают там эстимейты, а потом строят отчеты. Но это отнимает огромное количество времени, и если проект в работу так и не взяли, то он становиться бесполезным грузом.
Мне очень часто приходилось сталкиваться с оценкой, как частей проекта и конкретного функционала, так и целых проектов, начиная от невнятной идеи заказчика. Это реально очень сложно и утомительно. Также это осложнялось тем, что компания, где я работал, а вернее все компании, где я работал, пытались повесить на меня кучу лишних обязанностей, которые я не очень люблю. И вместо создания архитектуры для продукта и помощи разработчикам в его создании, и доведения его до продакшена, меня вечно отвлекали на пресейлы.
Я много лет реально промучался с этой рутиной, каждый раз выполняя одни и те же действия, как обезьяна, оценивая проекты, фичи и таски для клиентов. И всегда бизнесу это нужно было на вчера. Меня из архитектора превратили в какого-то сейлза, от чего у меня невероятно начинало пригорать. И в какой-то момент я понял, что уже начинаю сдавать морально, и что пора что-то с этим делать. И я стал продумывать, как мне упростить свою жизнь. Вначале я пытался создавать проект в Jira, как я встречал это в других компаниях. Но это отнимало много времени и сил на настройку и структуру проекта. Стало скапливаться много независимых друг с другом проектов, многие из которых не уходили в работу. Это было жутко неудобно. Потом я начал сохранять эстимейты в виде текстовых закладок, потом создавал мелкие ��айлы и перепробовал много чего еще. Все это было неудобно и не давало гибкости и простоты в быстром переиспользовании уже проделанной работы.
И тогда я понял, что придется делать что-то свое, дабы убрать с моих плеч эту рутину. Задачу я себе поставил такую: нужно разбивать бизнес требования на маленькие задачи, которые я могу оценить в часах, как минимальное и максимальное время выполнения. Задачи должно быть легко создавать, сохранять и быстро находить. Из этих задач можно быстро собирать фичи (функционал). Я это видел как редактор, создал фичу и накидал туда готовые таски. При этом мне нужно было, чтобы эта фича уже сама посчитала все эстимейты исходя из тех задач, из которых она состоит. Таким образом я смогу накапливать функционал, который я уже описал и оценил. Следующий момент - это возможность создать новый проект для пресейла нового запроса от клиента. Быстро заполнить его фичами, а если чего-то у меня в базе нет, то создать только это и не более того. И конечно же быстро это сохранить в PDF файл, с простой, понятной структурой, где будет все описано подробно и понятно для заказчика. Ну а по мере необходимости я буду добавлять уже новый функционал.
И я сделал для себя черновой проект на NodeJS и ReactJS, и использовал его для своих целей. Потом понадобилось подключать и других инженеров для оценки времени, так как большие проекты декомпозировать и оценивать в одиночку очень сложно. И для этого пришлось добавлять возможность приглашения конкретного сотрудника, а сам проект сделать онлайн. После чего нужен был экспорт уже готового проекта в какую-нибудь систему прожект менеджмента.
Но проект стал усложняться и разрастаться, и в итоге, я решил сделать SaaS-сервис. Назвал его соответственно - Presale.Ninja Чтобы название проекта говорило само за себя. А нинзя, потому, что это крутой уровень мастерства :-) На самом деле домен .com и все другие были заняты, а нинзя свободен, вот и все дела. Весь функционал полностью бесплатный. Единственное ограничение я сделал на количество итоговых задач в самом проекте. Это 30 задач, которые высчитываются из фич. Для большинства нужд небольших проектов этого достаточно, а фрилансерам так и подавно. А если нужно больше, то можно докупить, стоит это копейки. Для крупных проектов компаний, стоимость создания большого проекта будет обходится в 10 - 20 раз дешевле, чем эстимейтить по старинке.
Как это работает? Когда вы только начинаете пользоваться сервисом, вам не уйти от стандартного подхода декомпозиции и оценки задач. Но зато ваши инженеры могут работать не по одному, а сразу командой, создавая в сервисе задачи, которые будут оценены с минимальным и максимальным эстимейтом на выполнение. К задаче можно прикрепить все файлы, связанные с ней. Позднее это пригодится, когда проект нужно будет импортировать в систему управления проектами.
Задача (task) — это минимальный элемент, являющийся продуктом нашей декомпозиции. У задачи есть заголовок и описание (title и description). Также, как было сказано выше, к задаче можно добавить файлы, которые к ней относятся. У задачи есть автор. Для быстрого поиска задач можно добавлять к ним различные теги (tags), которые можно создать в разделе тегов. Теги сильно облегчают поиск, когда нужно что-то быстро найти. И, естественно, у задачи есть два поля для эстимейтов в часах — минимальный и максимальный.
Теперь, когда у нас есть большое количество мелких и хорошо описанных задач, мы можем создавать фичи (feature). Фича состоит из ряда этих мелких задач. Например, функционал "Регистрация". Он включает такие задачи, как создание миграции в базе данных, создание моделей для таблиц, создание контроллеров и API для регистрации и авторизации, формы регистрации и авторизации на фронтенде, дизайн, верстка и т.д. Создание фичи также легко, как и создание задачи, даже проще. Нужно создать фичу, заполнить заголовок и описание, прикрепить теги для быстрого поиска, а затем в разделе билдера (builder) наполнить фичу соответствующими задачами. Это, также, задача инженера. В итоге будет создана фича с описанием, списком задач, автором и суммарным эстимейтом от минимума до максимума. Все это сохраняется в облаке сервиса для компании, которая создала этот функционал. В дальнейшем не нужно будет снова проводить эстимейты того, что уже содержится в базе. Можно все это переиспользовать в новых проектах.
Далее нужно создать проект, который может создать сам менеджер по работе с клиентом. Проект также содержит заголовок, описание, возможность добавить теги. После этого можно перейти в билдер проекта и выбрать фичи, которые нужны клиенту для этого проекта. Менеджер может сделать все это самостоятельно, не отвлекая инженеров от их работы. Если окажется, что нужной фичи нет в базе знаний, менеджер может привлечь инженеров, чтобы те помогли создать недостающие задачи и фичи для проекта. Можно приглашать коллег через раздел инвайтов (invite), назначая им соответствующие роли для доступа к определенному функционалу сервиса.
После этого можно просмотреть, как будет выглядеть финальный документ в предпросмотре (preview), и сохранить его в формате PDF для передачи клиенту. Это будет полноценный документ, содержащий заголовок и описание проекта, список всех фич и задач, а также эстимейты — для фич, задач и для всего проекта. Фича в документе будет отображать сумму всех эстимейтов своих задач. Документ будет содержать заголовки и описания для всех фич и задач в иерархическом виде, что поможет клиенту понять, за что ему предстоит заплатить. Чем более подробно будут декомпозированы задачи с минимальными эстимейтами, тем выше вероятность устранить вопросы клиента о стоимости или сроках. Все будет перед глазами, ясно и очевидно. Это значительно повысит вероятность получения этого заказа.
Меня попросили добавить в сервис еще одну возможность. А именно шапку и футер для проекта (Header & footer). Это нужно, чтобы в шапке указать логотип и контакты компании, которая произвела пресейл проекта. А в футере, внизу документа, добавить дополнительную информацию. Например, что это не окончательные расчеты, и все подлежит обсуждению. Что в эстимейты не входит время на прожект менеджмент и тестирование, и т.д.
Когда проект будет принят в работу, возникнет вопрос о том, какие фичи и задачи нужно создать для разработчиков и на какую документацию им опираться. Для этого проект можно экспортировать в формате JSON, а затем импортировать его в систему управления проектами. При экспорте проекта вы получите ZIP-файл, содержащий ваш проект в формате JSON, а также папки с названиями задач из проекта, в которых будут находиться файлы, относящиеся к соответствующим задачам.
Сервис не заставляет вас действовать по определенным шаблонам, и вы можете построить гибкую систему, применяя разные подходы в создании задач и фич, которые будут подходить именно для вашей компании и команды. Все зависит от вашего воображения. Система поиска по тегам и строка поиска по текстам в заголовках и описаниях значительно упростят вашу работу.
Вот и все — очень просто и эффективно. В итоге сервис может сохранять всю базу знаний по предыдущим эстимейтам, уменьшить зависимость от инженеров, быстро создавать новые проекты, создавать профессиональную документацию, а также переносить проекты в систему управления проектами. Лично меня это полностью избавило (почти избавило) от рутинных операций и сократило потери времени. А для компании повысило экспертизу в глазах клиентов.
P. S. Был один курьезный случай. Маленькая WEB студия из трех человек сделала через сервис оценку проекта, по запросу заказчика. И заказчик согласился с ними работать. Они были в шоке, как так получилось. Этот заказчик делал запрос также в среднюю аутсорсинговую компанию. И та выдала ему эксел файлик на одну страничку, примерно с такими же эстимейтами, и в таком же виде, как я рассказывал вначале статьи. И заказчик решил, что эта аутсорсинговая компания и есть подвальная студия, а эти ребята из студии - это реальные профессионалы. Как гласит старая мудрость: "Встречают по одежке". Всем удачи в ваших начинаниях!
Уже после написания статьи я добавил ИИ ассистента, который помогает создать описание для тасок, фич и проектов. Работает очень просто. Нажимаете на кнопку ИИ ассистента и вводите запрос, какое описание нужно создать. Например, "Создай описание для задачи создания формы регистрации на фронтенде на реакт. Описание должно быть в сжатом виде не более 600 символов." После небольшой обработки запроса, в форму описания будет вставлен текст, созданный ИИ. Это очень упрощает жизнь, чтобы из головы не придумывать что-то непонятное. Текст потом можно поправить или опять воспользоваться ИИ ассистентом, переделав запрос.
