solovladys
@solovladys
Люблю программировать

Как самостоятельно оценивать объем работы и стоимость разработки?

Недавно получил предложение от приятеля разработать его "супер-проект". Задача заключается в том, что я разрабатываю API для их мобильного приложения. В основном это стандартное приложение с авторизацией, категориями, контентом и поиском ближайших заведений.
До этого только работал в компаниях, и командах, где не приходилось самостоятельно оценивать объем работы по времени и стоимости. Подскажите с чего стоит начать процесс оценки времени и как оценивать работу разработчику уровня java middle?
  • Вопрос задан
  • 622 просмотра
Пригласить эксперта
Ответы на вопрос 5
RAFAILgaley
@RAFAILgaley
ну всё е просто -

оцениваешь свой час работы, или месячную плату при полной занятости

и приблизительно оцениваешь время на разработку и тестирование
с запасом раза в полтора-два

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

дорого долго прекрасно


ты либо с запасом определяешь сроки, либо в спешке и стрессе работаешь
стресс и спешка несовместимы с качественным дизайном
для хорошего дизайна важно работать в хорошем настроении
Ответ написан
@FernandoErrNando
обычно есть 2 пути:
  1. Оценка по фикс-прайсу
  2. Или Time&material.

Первый путь начинается с анализа ТЗ, конечно же. Иногда, у заказчика есть какое-то описание в виде текстового файлика, мокапа, дизайна или ещё чего-нибудь. Если же нет, то тебе придется как-то формализовать его хотелки, перевести в понятный вид и написать тз самому, не для него, а для себя прежде всего. В нем ты описываешь весь функционал, который требуется, поведение пользователей, примерные нагрузки и т.д.
Чем детальней написано тз - тем лучше.
Например:
Плохое ТЗ: В приложении можно авторизоваться через email/соцсети.
Хорошее ТЗ: В приложении можно авторизоваться через email и соцсети facebook, vk, instagram. Пользователь может проходить авторизацию через любую соцсеть, при этом при авторизации через ещё непривязанную соцсеть мы должны обновлять данные пользователя.

Дальше ты разбиваешь ТЗ на отдельные части, которые ты можешь оценить.
Например:
Авторизация по email: 2-3ч + 3-5 на каждую соцсеть.
На те вещи, которую ты знаешь и много раз делал закладываешь разброс поменьше, то что не делал - побольше. НА интеграции с третьесторонними сервисами типа соц.сетей, платежных систем, закрытых API, невнятно описанных вещей в ТЗ и т.д. делаешь большой рейндж, т.к. велик риск проблем с доступами, сложностей получения, неактульных документаций и прочим. Если что-то непонятно, лучше спросить у заказчика заранее и описать возможные проблемы, возможно, вы найдете другое решение.

В конце концов у тебя получится 2 оценки - оптимистичная и пессимистичная. Можно ещё добавить какой-нибудь коэффициент, на который надо умножить, если твои оценки обычно слишком оптимистичны ("да тут работы на 2 дня", а сидишь неделю) или наоборот, излишне пессимистичны ("мне надо месяц, а делаю за неделю").

Далее ты понимаешь работа займет, к примеру 250-300 чч, умножай её на свою часовую ставку. вот ты и получил примерную стоимость работ. Не забудь прибавить стоимость всех материальных затрат, специфичных для (хостинги, доменное имя, спец. оборудование, доступ к платному АПИ).

Также не забудь учесть, сколько ты сможешь работать, а то он может подумать, что это 250чч - это 1 месяц работы, а в реальности у тебя основная работа/семья/кошка и ты можешь дать только 100чч/месяц.

2 путь сложнее:
Заказчик любит менять концепцию, тз нет и не будет ему важно быстро тестировать свои идеи и что в итоге выйдет он плохо себе представляет - тогда ты просто ему озвучиваешь стоимость часа и сколько времени ты можешь ему уделить. Основные сложности - это то, что можно нагородить говнокода из-за постоянных изменений, и каждая дальнейшая правка будет занимать все больше времени, а рефакторинг в таком случае очень трудно продавить.
Ответ написан
Комментировать
@vitaly_il1
DevOps Consulting
С ценой все просто - берем зарплату, делим на 190 часов, умножаем на 1.4 - получаем цену часа.

Оценить время - непросто. Надо
1) описать проект - что заказчик получит на выходе
2) разбить проект на задачи, под-задачи, и так далее, пока не дойдем до задач, которые мы умеем оценить по времени.
Если проект не определен, то ес-но, оценить по времени не получится, и остается работать по времени (что я лично и делаю).
Ответ написан
saboteur_kiev
@saboteur_kiev
software engineer
Так ты ж работу выполняешь. Неужели как мид разработчик не можешь оценить сколько времени у тебя займет этот проект? Заложи на непредвиденные обстоятельства проценты согласно своему опыту (только ты знаешь как часто у тебя возникают непредвиденные раньше проблемы, только ты знаешь как быстро ты работаешь)

И умножь получившееся время на ЗП, которую ты предполагаешь получать.
Ответ написан
Mesuti
@Mesuti
Оценивать себя можно как угодно, хоть за миллион.
Но какой в этом смысл, если дядя Вася сделает дешевле? =)

А еще, работать на друзей - потерять дружбу.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы