Оценка проекта на мобильную разработку. Что происходит с вашей заявкой после обращения в компанию

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

От качества оценки зависит решение потенциального заказчика, имидж компании и дальнейшие отношения с клиентом, поэтому важно держать в голове три нюанса:

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

МегаФон ПроБизнес

Получите Кешбэк 100% за запуск рекламы с МегаФон Таргетом!

Узнать больше >>

Реклама. ПАО «МегаФон». ИНН 7812014560. ОГРН 1027809169585

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

1. Первый контакт с клиентом. Это может быть заявка на сайте, электронное письмо или сообщение в каком-нибудь мессенджере. Причём всегда, конечно, приятно, когда клиенты связываются с нами самостоятельно.
2. Знакомство с компанией — непосредственное общение сотрудника отдела продаж и клиента. Это необходимо, чтобы узнать друг друга получше и не тратить лишнее время, если общего языка найти не получается.
3. Подписание NDA, ведь идеи и чужие бизнес-процессы — интеллектуальная собственность и коммерческая тайна.
4. Передача требований для оценки.
5. Уточнение деталей.
6. Оценка проекта.
7. Составление коммерческого предложения.
8. Презентация решения, предлагаемого компанией.
9. Обратная связь.
10. Принятие решения о дальнейшем сотрудничестве.

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

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

Что должен сделать клиент перед обращением к разработчику

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

Необходимо задать себе вопрос: «Что я хочу получить от процесса поиска исполнителя?». Как минимум есть два варианта ответа на этот вопрос:

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

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

Конечно, эти ситуации можно разбить на ещё несколько пунктов, но в текущем контексте частности не сильно влияют на цель составления оценки проекта.

Конечная цель всего этого мероприятия (оценка проекта) — заключение соглашения с наиболее подходящим исполнителем.

Добавлю, что ТЗ, написанные по старинным ГОСТам и в объёме в сотни страниц, не помогут получить быструю и правильную оценку для проекта. Работа с таким документом будет утомлять исполнителя. Более того, все аспекты всё равно не описать в одном документе, да ещё и так, чтобы получилось то, что хочется. Поэтому рекомендуем использовать графические элементы для описания требований. Будь то схемы, диаграммы или макеты приложений. Разумеется, что последние будут наиболее полезными для анализа проекта.

Кто оценивает проекты

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

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

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

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

Как оценивают проекты

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

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

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

Но повысить точность оценки можно. Приведу пару примеров.

1. В случае если разработчик делает это в одиночку, то он даёт три оценки: оптимистичную, пессимистичную и реалистичную. Вычислив среднее, получаем более точную оценку, чем каждая из исходных по отдельности.
2. Если в этом процессе помогают коллеги, то используются методы коллективной оценки. Существуют разные способы получения общей оценки группы специалистов, от банального вычисления среднего до различных игровых методов.

Делать больше, чем требуется: extra mile

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

Эксперт видел изнутри далеко не один и не два проекта. А уж сколькими различными продуктами пользовался, даже страшно представить.

Лучше приложить к оценке какой-нибудь бонус. Например:

1. Советы по изменению функциональности или даже самой идеи, если это приемлемо.
2. Советы по организации архитектуры.
3. Эскизы, если частью предложения является графический дизайн.
4. Экспертное мнение по поводу возможной успешности проекта.

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

Выбор исполнителя. Фрилансеры или компании?

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

1. Обратиться к фрилансерам.
2. Обратиться к компании, которая занимается разработкой ПО на заказ.

Плюсы и минусы фрилансеров

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

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

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

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

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

Плюсы и минусы компании

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

• Всегда кто-то сможет подменить разработчика.
• Компании обычно сильнее переживают за свой имидж, а потому будут сильнее заинтересованы в том, чтобы вы были довольны.
• Вы сможете получать дополнительный сервис, как правило, абсолютно бесплатно (например, управление проектом, сопровождение и тестирование), при этом работу будут выполнять разные люди, так что разработчик не будет отвлекаться.

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

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

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

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

Инструкция по оценке проекта для разработчиков

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

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

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

Но мы всё-таки попробуем, ведь обычно в таком формате заявки к нам и поступают.

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

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

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

Для начала необходимо понять, какие приложения надо разработать.

В нашем случае это:

• серверное приложение;
• веб-приложение для сотрудников компании;
• iOS приложение для клиентов;
• Android приложение для клиентов;
• веб-приложение для клиентов.

Теперь необходимо разбить каждое приложение на модули. Например:

Серверное приложение:

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

Веб-приложение для сотрудников компании:

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

iOS-приложение для клиентов:

• модуль авторизации и регистрации;
• модуль просмотра каталога товаров;
• модуль работы с заказами;
• модуль оплаты;
• модуль обработки ошибок;
• модуль обработки уведомлений.

Android-приложение для клиентов: аналогично iOS-приложению для клиентов.

Веб-приложение для клиентов: аналогично iOS-приложению для клиентов.

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

Оценивать проект следует в трудозатратах (человекочасах), ведь именно время ваших людей составляет стоимость работ.

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

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

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

В нашем случае она может выглядеть так:

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

Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на 42@cossa.ru. А наши требования к ним — вот тут.