Каждый разработчик так или иначе оценивает свои задачи. Со временем и опытом часто приходится оценивать не только свои задачи, но и проекты в целом. От обычной оценки задач уже планируется итоговая смета проекта. Клиенты разумно хотят прикинуть стоимость услуг вашей компании и это единственный способ это их желание как-то удовлетворить.
Я Android-разработчик, который волею судеб стал разбираться в iOS из-за необходимости управлять и направлять iOS командой. Нахватался опыта и там и там, стал человеком-оркестром с функциями менеджмента. Одной из моих обязанностей как раз и была оценка, прогнозирование сроков и умение управлять несколькими проектами на разных платформах одновременно. В маленькой компании ты всегда намного ближе к бизнесу и все эти вопросы так или иначе проходят и через тебя. Это всё дало хороший опыт оценки нативных мобилок, даже в такой небольшой компании просто неприличное количество факторов, о которых стоит задумываться оценивая и собирая смету клиенту.
Что учитывать?
- Насколько много сейчас известно о требованиях (на словах / документ с требованиями / макеты);
- От качества этих требований;
- От текущего состояния тех компонентов, с которыми нужно интегрировать приложение, например бэкенд или какая-то библиотека клиента. Готовы ли они, или будут разрабатываться параллельно?
- Кто разрабатывает бэкенд, базу и поднимает всю эту инфраструктуру? Как легко будет с ними взаимодействовать?
- Насколько компетентна команда в этом бизнесе;
- От технической сложности;
- Насколько компетентна команда в подобных технических решениях;
- Сколько человек мы хотим выделить на проект;
- Насколько загружены эти люди будут в момент когда им нужно будет работать над проектом;
- Каковы риски по каждому участвующему работнику? Может они выгорели, может хотят уволиться, а может кто-то наоборот на невероятном подъёме;
- Насколько нам важно сконнектиться с клиентом для дальнейшего сотрудничества;
- Насколько наша жизнь как компании вообще зависит от этого проекта;
- Насколько вообще клиент адекватен и насколько вы друг другу доверяете;
- Стоимость содержания одного человека в компании, затраты на офис, технику, зарплата сотрудников необходимых на функционирование компании, но явно не принимающих участие в разработке; …и всё в таком духе.
Общие принципы
- Делать выводы из своего предыдущего опыта, учиться на ошибках;
- Чем меньше понятно и реализовано на момент оценки - тем больше закладывать рисков. Естественно большую часть факторов просчитать почти невозможно, поэтому у любой оценки будет какая-то часть в виде рисков;
- Если клиент не хочет оплачивать риски в таком объеме, то двигаться с ним по шагам. Так ему будет понятнее, каждый из шагов отдельно оценивается и оплачивается, согласовать макеты, спецификацию API для приложения, разрабатывать сначала MVP, потом усложнять новыми требованиями.
- Чем важнее и перспективнее клиент - тем меньше стоимость, в долгосрочной перспективе такие связи окупаются засчёт поддержки и постоянного потока проектов, возможно мы сейчас хотим подемпинговать, чтобы инвестировать в будущее;
- Если оценку клиент отдельно не оплачивает, то время, затраченное на оценку равномерным слоем размазывается по всем пунктам;
- One man team всегда посчитать проще, на взаимодействие между людьми и менеджмент нужно добавлять определённый процент сверху;
- Есть люди разного уровня компетенций - оценку для них усредняем.
- Разбивать требования на подпункты настолько, чтобы каждую оценку можно было с каким-то допущением посчитать. Например: отдельно пуши, авторизацию с помощью соцсетей, и всякие такие типовые задачи, которые примерно понятно как делать - записать отдельно, оценку по ним посчитать проще всего. Всякие бизнес-специфичные требования часто посчитать сложнее всего, да ещё и клиенты часто хотелки свои на ходу вставляют. С определёнными рисками вносим и их, суммируем - получаем итоговую оценку.
- Давать оценку с некоторым разбросом;
- Доносить эту оценку человеческим языком, мочь объяснить почему нарисовать такой компонент - 1 день, а вот другой похожий - 101 день.
- Как считать итоговую оценку у каждого свои подходы из-за того, что людям свойственно её приуменьшать. Кто-то просто на 3 умножает, кто-то на пи + две недели. Я привык считать min и max, а клиенту на согласование отдавать avg..max.
Сколько стоит?
Насчёт того сколько это вообще может стоить - сколько угодно. Грубо говоря нужно эту оценку домножить на среднюю зарплату задействованных лиц и их количество + какой-то процент сверху для развития компании + накладные расходы для функционирования офиса, например. Всё это очень сильно может варьироваться. От страны и города, от офиса, от плюшек в компании, и так далее.
Android vs iOS
По моему опыту оценка Android и iOS если усреднить по фичам - не отличается почти ничем. В Android есть свои особенности, в iOS свои, на какие-то задачи оценка будет существенно отличаться, но если размазать на весь проект, то примерно то на то и выходит. It depends, опять же, от наличия нужных кадров и от требований.
Если сначала сделано под Android, а потом планируется делать под iOS, то это уже гарантия того, что хоть какие-то макеты были, бэкенд реализован, требования устаканились, результат работы принят, а андроид команда совершила кучу работы по придумыванию архитектуры, имеет какие-то готовые модели, описанную базу данных, например. Если она может передать знания iOS команде, то это существенно срезает косты второму. То же самое и в обратную сторону.
Кроссплатформу я в своих рассуждениях, скорее всего, покрываю не очень хорошо, но там тоже всё зависит от приложения и насколько много работы с платформой происходит, если ты делаешь приложение для просмотра новостей, например, и кроме текста с картиночками из интернета тебе ничего больше не нужно, то кроссплатформа хороша, перенесётся почти целиком. А вот если тебе нужна какая-нибудь камера по полной, какие-нибудь железные датчики, то едва ли не проще два разных нативных приложения написать.