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

За год мы не выросли вообще. Совсем.

Как мы жили «до»

Наша система оценки была построена на часах. Клиент спрашивал: «Сколько времени займёт эта фича?» — и мы садились прикидывать. Разработчик называл 20 часов, я накидывал сверху ещё 30% «на всякий случай», проджект-менеджер страховал ещё немного. В результате появлялась цифра, которая не имела почти никакого отношения к реальности.

Думаю, вы знаете, что было дальше. Какая-то задача, оценённая в 8 часов, не закрывалась к вечеру пятницы, потому что внутри неё сидел мелкий неизвестный подводный камень. Разработчик сидел до ночи, потому что «срок же», и приносил результат во вторник — уставший, злой и с тихой ненавистью к задаче. Я нервничал, потому что бюджет горел. Клиент нервничал, потому что «мы же договаривались». И вместо конструктивного диалога о продукте мы общались на языке оправданий.

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

Почему Scrum и Story Points

В IT-сообществе про Scrum и сторипоинты не говорит разве что ленивый. Вся команда — опытные люди, все примерно понимали, о чём речь. Когда на одной из планерок я сказал: «Давайте попробуем оценивать не время, а сложность», — я увидел не сопротивление, а облегчение. Наверное, этот момент был самым красноречивым. Команда устала от огромного потока задач, так как оценивалась время задачи и давалась ровно на то кол-во часов, на которые устроен сотрудник.

Мы внедрили Scrum с его стандартными ритуалами и перешли на оценку в Story Points. Без революций, без дорогих консультантов — просто договорились о внутренней валюте сложности.

Что изменилось — один кейс и глобальные сдвиги

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

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

В новой реальности мы оценили задачу по сложности — командой, в покере планирования. Она получила, скажем, 30 поинтов. Что очень много... Мы стали ее сразу дробить до минимума в 8 поинтов. И какое для нас было удивление, что после дробления это задача превратилась из 30 в 80 поинтов (я условно называю цифры, чтобы передать суть). И это уже были четко декомпозированные задачи в которых сразу были учтены возможные блокеры.

И вот как это ощущается глобально.

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

Качество поднялось. Не потому что тестировщик стал работать больше. А потому что разработчик перестал судорожно закрывать таски, глядя на тикающие «человеко-часы». Ушло это мерзкое чувство: «Я уже потратил 4 часа из 6, а конца не видно, значит, надо среза́ть углы». Сейчас задача делается столько, сколько требует её сложность. Если наткнулись на неизвестное — это становится аргументом в ретро, а не причиной для паники в субботу ночью.

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

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

Мысль, которую я хочу донести

Многие основатели небольших студий ищут волшебную таблетку для роста. Так вот, Scrum и Story Points — не магия. Это просто чувствительная система. Она делает разработку прозрачной и честной — сначала внутри команды, а потом и для клиента. Оценка по времени делает вид, что мы контролируем непредсказуемое. Оценка по сложности признаёт: в творческой интеллектуальной работе может случиться что угодно, и это нормально. И когда вы это принимаете, система начинает работать на вас, а не против.

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

Комментарии (9)


  1. AndruxaBS
    11.05.2026 09:52

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


    1. seregatot Автор
      11.05.2026 09:52

      В этом и проблема была, да. Многие заказчики, в том числе и наш, боялся что работа по факту может быть искусственно завышена нами, и был бы в этом какой то степени прав. Никто бы не работал в обыток.
      Но как решили проблему мы? Когда перешли на scrum, сама его суть говорит о том, что не может одна задача занимать больше 8 поинтов (условно). То есть мы начинали ее декомпозировать на более мелкие, что в итоге и дает "реальный" объем работ. И когда заказчик спросит "почему так дорого" - то у нас уже есть четко декомпозированная его задача, и если заказчик адекватные, то он примет это. А если заказчик настаивает на своем, то просто лучше от такого отказываться


  1. MEGA_Nexus
    11.05.2026 09:52

    Задачу на 80 поинтов ранее оценивали в 30 поинтов и клиент платил за 30 поинтов. Теперь такая задача оценивается в 80 поинтов и клиенту нужно оплачивать 80 поинтов, т.е. стоимость выросла, как и сроки. Клиенты готовы к такому?


    1. seregatot Автор
      11.05.2026 09:52

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


  1. turner-i
    11.05.2026 09:52

    Уже давно известно, что первоначальную смету нужно умножать как минимум на 3. :-)


    1. seregatot Автор
      11.05.2026 09:52

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


  1. self-taught-dog
    11.05.2026 09:52

    Огромное спасибо за информацию! Возможно вы только что спасли стартап


    1. seregatot Автор
      11.05.2026 09:52

      Очень рад! Именно для этого и веду блог :)


  1. Gendzi
    11.05.2026 09:52

    Сложилось впечатление, что ваша проблема была не в отсутствии Scrum, а отстутствии декомпозиции задач. Почему с часами вы гадали: 'что-то вроде 40', а с storypoint стали дробить сложность? Почему нельзя было начать декомпозировать задачи пользуясь часами, а не storypoint?