Бизнес план разработки it продукта

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

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

Жизненный цикл разработки IT-продукта

Ниже описаны этапы цикла, начиная с момента, когда заказчик сформулировал свои идеи исполнителю.

• Планирование

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

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

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

• Дизайн

После планирования наступает черед UX/UI дизайнеров — специалистов, которые проектируют пользовательские интерфейсы. Дизайнеры занимаются изучением поведения пользователей и выстраиванием понятного человеку интерфейса. Визуальный вид продукта — также результат работы дизайнеров.

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

• Разработка

Разработчики следуют одной из методологий — для компании это в основном Agile. Эта методология предполагает гибкий итеративный подход — то есть разработчики действуют последовательно, разделяя проект на более мелкие задачи.

Итерации в Agile называются спринтами, и в один спринт входят работы по всем направлениям: планирование, дизайн, разработка, тестирование.

• Тестирование

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

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

• Поддержка

Готовый продукт может нуждаться в дополнительной поддержке, будь то дополнительные вопросы по поводу работы продукта от клиентов, или необходимость внести изменения в уже заложенные функции, — специалисты службы поддержки всегда готовы прийти на помощь.
Большинство проектов по разработке проходят все этапы вышеописанного жизненного цикла.
Для примера мы подробнее рассмотрим процесс разработки продукта на текущем проекте компании.

Этап 1: Идея

Заказчик — печатная компания из штатов. По всему миру эта индустрия переживает не лучшие времена, но в США печатные компании остаются на плаву благодаря инновационным технологиям. Печатная компания обратилась к нам с просьбой разработать приложение для дополненной реальности — Augmented Reality, AR.

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

Этап 2: Контакт

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

Этап 3: Планирование

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

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

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

Комментарий менеджера проекта Александра:
«Я отвечаю за непрерывный ход проекта. Я выбрал Scrum-методологию, чтобы быстро реагировать на запросы заказчика и рынка. Scrum помогает нам развивать продукт, учитывать потребности пользователей в каждом релизе продукта, и использовать в разработке самые современные технологии».

Этап 4: Дизайн

Заказчик был открыт к любым идеям наших дизайнеров и доверял видению специалистов. UX/UI дизайнер описал своё представление будущей системы, основываясь на общепринятых UX практиках, заказчик согласился, и началась реализация дизайна.

Этап 5: Разработка и тестирование

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

На первом этапе разработки команда состояла из:

• Менеджера проектов, который также выполнял задачи бизнес-аналитика;
• UX/UI дизайнера;
• команды разработчиков.

На начальной стадии разработчики проводили тестирование своими силами, без участия QA-специалистов. Задача заключалась в том, чтобы создать набор прототипов для демонстрации на конференциях и привлечения потенциальных клиентов. Тогда детальное тестирование не понадобилось.

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

• Менеджер проектов;
• Бизнес-аналитик с более широким кругом задач, чем были у менеджера до этого;
• UX/UI дизайнер;
• разработчики;
• руководитель команды разработчиков (Team Lead);
• Системный архитектор, разработавший структуру продукта;
• Специалист по тестированию;
• DevOps — связующее звено между разработкой и эксплуатацией, работал с сетью и развертыванием продукта.

Руководитель команды разработчиков Игорь внес свои нововведения:
«В этом проекте я отвечаю за выполнение задач проекта, провожу рецензию кода, планирую спринты (итерации в разработке), ввожу новые задачи. Я предложил проводить юнит-тесты с помощью GitFlow и создавать код при помощи AWS Lambda. Я также ввожу в курс дела новых членов команды, отвечаю за их адаптацию”.

Присоединение Team Lead было важным решением, так как он помог скоординировать разработку версий приложения под iOS и Android и веб-версию так, чтобы все двигалось в одном направлении.

Бизнес-аналитик Флор рассказывает:
“Благодаря организации проекта, моя работа была предельно ясной и эффективной. Я обрабатывал запросы клиентов и в понятном и технически точном виде передавал их команде разработчиков. Я работал в тандеме с UX/UI дизайнером, а наш проект менеджер был ответственным за переговоры, что дало мне возможность сфокусироваться на моих основных задачах»,

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

Этап 6: Поддержка

Поддержка обычно осуществляется на 3 уровнях:

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

Существует также нулевой уровень поддержки через брошюры и руководства по эксплуатации.

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

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

Меня всегда занимал вопрос, как создаются компании и организации, как образуются те центры самоорганизации, на которые осаждаются сотрудники и ресурсы из совсем даже не насыщенного «раствора» внешней среды.

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

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

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

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

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

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

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

Мне повезло наткнуться на совершенно свободную нишу, в которой у меня совершенно не было конкурентов. Заказчиков там, правда, тоже не было — чудес ведь не бывает, но со временем они начали появляться без каких-либо расходов на рекламу, холодных звонков, тендеров, откатов и прочих ужасных вещей, которыми приходится заниматься многим компаниям. Разумеется, на меня играл статус официального партнера по данному продукту (тоже далеко не бесплатный), а так же репутация одного из лучших русскоязычных экспертов по нему, которая образовалась как побочный эффект от попыток популяризировать Moodle в России. Думаю, это ключевые факторы того, что мне не пришлось «свернуть лавочку» еще много лет назад.

В какой-то момент нам удалось накопить на счету «целых 500 тысяч» и мне показалось, что пора обзавестись офисом и штатом. Мой оптимизм поубавился, когда 100 тысяч ушло на одну только офисную технику, но тем-не-менее, я нанял двух программистов и секретаршу и снял офис неподалёку от дома. Следующие полтора года были ужасающими, особенно первые 6 месяцев. Сам удивляюсь, как мне удалось избежать инфаркта. Каждый месяц мог оказаться последним, но каким-то чудом в последний момент удавалось находить деньги, чтобы заплатить зарплату, аренду и налоги.

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

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

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

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

Вместо неё нанял ассистента, в обязанности которого входило освобождать меня от всей работы, которую нельзя поручить программистам. Поиск подходящей кандидатуры занял почти год. Зато сразу после её найма компания «ожила» — зашевелились перспективные проекты, стали активнее появляться клиенты, ускорился подбор и обучение персонала. Удивительно, как много вещей тормозиться, когда руководитель находится в постоянном «цейтноте».

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

Как удалось выяснить опытным путём, стабильная работа компании возможна при достаточной ритмичности обработки заказов. Для этого месячный оборот должен быть хотя бы на порядок больше единичного заказа. Если вы выполняете единственный заказ целый год, а затем ищете следующий — ни о какой стабильности и не мечтайте: клиенты не будут ждать, пока вы освободитесь, а когда освободитесь — не сможете быстро найти новый заказ. По этой причине пришлось отказаться от участия в тендерах и заказов, требующих объемного проектирования: мы просто слишком малы, чтобы этим заниматься. Такое могут позволить себе крупные компании, а наша компания просто загнется, если я позволю себе 2 месяца заниматься только написанием проектной документации под один заказ.

Вместо этого, мы перешли на методологию экстремального программирования: исполнение заказа начинается сразу же, после постановки задачи и минимального проектирования, без детального проектирования, необходимого для составления сметы. Клиент максимально вовлечен в исполнение своего заказа — видит ежедневные отчеты по расходованию часов и полученным результатам, еженедельно получает микро-релизы для ознакомления с разработанным функционалом. А в крупных проектах мы участвуем на субподряде у компаний, у которых есть штатные специалисты по тендерам, проектные менеджеры, системные аналитики, технические писатели и прочие инструменты убеждения клиента в целесообразности и надежности затрат. Хотя по-факту, эффективнее закладывания в смету многократного (иногда на порядки) запаса стоимости для предварительной оценки программного проекта еще никто ничего не придумал.

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

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

И, напоследок, совет начинающим предпринимателям, который бы мне очень помог 8 лет назад: «Не делайте этого!»