company_banner

Оценка трудозатрат в разработке ПО для начинающих

Автор оригинала: Allen Helton
  • Перевод

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

Помню, как меня впервые попросили дать оценку…

Тогда это застало врасплох.

Меня завели в кабинет, где были мой начальник, его босс и кто-то из вышестоящего руководства, и мы сели за круглый стол, уставившись друг на друга.

Аналитики зачитали некоторые требования от клиента. Мы их коротко обсудили.

И тут мой начальник повернулся ко мне и спросил: «Сколько времени это займет?»

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

И вдруг на меня все смотрят и ждут ответа, а я растерялся и не знаю, что сказать.

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

Где-то через минуту, которая показалась мне часом, я решил просто сказать первое, что пришло в голову: «Не знаю… часов 600?»

Начальник рассмеялся, а затем сказал остальным рассчитывать на примерно 1200 часов.

Не очень люблю вспоминать тот день.

Понятно, что мне еще многое предстояло узнать, но меня мучил один вопрос: как оценивать объем предстоящей работы?

Цель проведения оценки

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

Оценка объема работы используется в основном в двух целях:

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

  • Выставление счета клиенту.

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

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

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

Допустим, в вашей команде разработчиков три человека. Каждый работает по 40 часов в неделю — это примерно 160 часов в месяц, или 480 часов в квартал (на троих — примерно 1500 часов).

Представьте, что ваша команда должна выполнить пять проектов — с оценками объемов работ 800, 400, 300, 200 и 50 часов. Планируя загрузку, вы будете видеть, что не сможете к концу квартала выполнить все проекты. Менеджеры составят график, использующий определенный процент максимальной загрузки — на случай, если разработка займет больше времени, чем предполагалось.

С оценками из нашего примера можно было бы взяться за проекты на 800, 400 и 50 часов, и при этом осталась бы некоторая свобода для маневра.

Выставление счета клиенту

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

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

Примечание. Это применимо не ко всем компаниям — разработчикам ПО: не все занимаются разработкой на заказ. Если вы не разрабатываете ПО на заказ, то оценки объема работ будут использоваться в основном для планирования.

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

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

Фото — AbsolutVision, площадка Unsplash
Фото — AbsolutVision, площадка Unsplash

1. Не оценивайте, сколько времени понадобится ВАМ

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

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

Часто полезным будет предположить, что работу будет выполнять самый неопытный в команде.

2. Не занижайте — завышайте

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

Если разработчики выйдут за отведенный вами срок, это нарушит график работ.

Находиться в границах 20% — это нормально, но только если оценка оказалась завышена — а не занижена.

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

3. Повышение квалификации

Потребуется ли команде для выполнения проекта изучать что-то новое? Например, если вы обычно разрабатываете приложения для «толстых» клиентов, а новый проект — это создание веб-страницы.

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

Фото — Matheus Frade, площадка Unsplash
Фото — Matheus Frade, площадка Unsplash

4. Примеры аналогичных проектов

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

Если у команды имеется некий опорный материал в виде ранее разработанного ПО, то объем работы может значительно снизиться. Разработчикам проще действовать по принципу «копировать, вставить, заменить», и это отражается на скорости выполнения задач.

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

5. Не забывайте об аналитиках

Часто вас будут просить дать полную оценку, а она включает в себя время разработчиков, бизнес-аналитиков и специалистов по обеспечению качества.

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

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

Заключение

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

Со временем оценки будут даваться вам всё легче. Запомните перечисленные моменты, научитесь понимать, сколько времени занимает разработка определенных элементов, и полагайтесь на свой опыт.

Если резюмировать самое главное, запомните вот что:

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

Никто не будет злиться, если у вас всё пойдет по плану, — начальство даже порадуется! И при этом у вас останется больше времени на другие проекты.

Так что не стесняйтесь выделять побольше времени и помните, что оценка — это всего лишь оценка.


О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Alconost
Локализуем на 70 языков, делаем видеоролики для IT

Комментарии 14

    –2
    Не очень люблю вспоминать тот день.

    Тут я сообразил, что это — перевод (да, я смотрю текст прежде авторства). И вот что я скажу — в нашей культуре всё по другому. Наш мальчик терпит.
      0
      А еще, не достигший стадии принятия, наш мальчик минусует. Галеры, сэр.

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

      Похоже разработчики знатно перерабатывают.)
        0
        Не совсем :) Месяц = 4 недели = 4*40 = 160.

        Допустим, в вашей команде разработчиков три человека. Каждый работает по 40 часов в неделю — это примерно 160 часов в месяц, или 480 часов в квартал (на троих — примерно 1500 часов).


        Возможно, пояснение про 480ч добавили после твоего комментария.
        +1
        Чтобы научиться давать оценку объему работу, нужно время.

        Нужен опыт выполнения именно этой работы. Оценка объёма работы, которую ты никогда не выполнял — пальцем в небо, сколько бы ты ни практиковался в оценке других работ.


        Возле ворот города сидел мудрец. Выходящий путник спросил его, за сколько времени он дойдет до ближайшего города. Мудрец сказал: «Не знаю». Когда человек уже удалился на небольшое расстояние, мудрец сказал ему: «Я думаю, за 7 часов ты дойдешь до ближайшего города».
        Человек удивился, почему тот не ответил сразу. «Я хотел узнать, с какой скоростью ты двигаешься».
          0
          Но через час движения на дороге возникла пробка, изменился рельеф, появилась гора и в итоге путник дойдет до города не менее чем через 21 час.
            0

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

              0
              Если я пойду про проторенной асфальтированной дороге — я легко оценю трудозатраты. Но если же путь лежит через неизведанные горные тропы — вот и возникает вопрос.
              Притча к данному случаю не очень подходит. Выше уже описывали ньюансы.
              Банальный пример — интеграция ЯндексКассы на сайт. Я делал подобное лет 5 назад через простейшую email подгрузку за полчаса — три поля в форме и запрос на оплату уходит. Но они недавно сменили API и мне пришлось изучать новую логику. Потраченное время в разы больше, хотя я клиенту изначально обещал всё быстро. Вот вам и изменение ландшафта в процессе хотьбы до другого города.
                0

                Да, в вашем случае, сколько ни ходи, всё равно, как в первый раз. Так мудрецом не стать.

                  0
                  Так с современной модой на кучу фреймворков мудрецом никогда и никому не стать. Каждые полгода всё меняется и даже джуну «нужно всё это знать».
                    0

                    Возможно тот мудрец из притчи — FoxPro-программист.

          +2
          К какой бы цифре вы ни пришли, добавьте к ней 20%

          *200% :)
            +2
            Вот именно. Его начальник был намного мудрее, он сразу удваивал.
              0
              В законах Мерфи рекомендуют умножать на 2 и переводить в единицы более выкокого порядка. Так двухчасовая работа становится четырёхдневной, а трёхдневная — шестинедельной

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

            Самое читаемое