— финансовую отчётность ведём, отдельно не описывал, в статье обозначал что всё что связано с «потоками денежных средств» вынесено за этот кейс;
— квартальные планы, конечно же, ведём. Строим модель на год, она в двух вариантах: «прогнозная» (цель) и «плановая» (от реального роста клиента и новых совершённых продаж), далее горизонт планирования 3 месяца по этим моделям (обновляются обе) ежемесячно. Т.е. каждый след месяц — «план», два последующих — «прогноз». Так называемый «тех долг» по «прогнозной» модели размазываем на след кварталы до конца года (от этой модели ставятся OKR и KPI команде), при этом по «плановой» ведём фактическое сжигание объёмов для статистики только.
В остальном очень полезно, изучу и подумаю о внедрении.
При закрытии финансового года отличия могут достигать тысяч евро, но если погрешность с бухгалтерией держится в пределах 5% годового бюджета — можно сказать, что учет отличный.
Чем больше компания — тем меньше на неё могут повлиять риски от несовпадения управленки и бухгалтерии, можно позволить менее точечно контролировать расхождения и допускать погрешности. Тем более вы говорите о большой компании и всего тысячах евро расхождения.
Но тем не менее даже крупные компании стремятся погрешность минимизировать «в пределах 5%» и это ну совсем не «от слова никак» ;)
У нас компания до 200 человек и мы уделяем много внимания полному совпадению бумаг и приходов/расходов. Да это очень сложно, при том что зачастую клиенты хотят и переплатить вперёд до актов (из-за того что у них годовые бюджеты) и надо морочиться с амортизацией по группам закупок и т.д. Зато риски минимизированы. А так — каждый сам принимает решение какая вероятность наступления этих рисков и их степень влияния на его компанию.
Зачем это вам, если вам достаточно знать всего лишь две цифры — стоимость нормочаса и общее количество доступных нормочасов на проекты, при которых эта стоимость считалась?
Мы заказная разработка, на данный момент у нас более 65 проектов в активной стадии разработки (веб или мобильные приложения) с совершенно разными тех стеками. Из-за особенностей заказной разработки приходится быстро масштабироваться в том числе и на короткосрочные проекты заказчиков. Поэтому приходится тюнить процессы рекрутинга и управлять на коротком горизонте планирования (3 месяца) приоритетами и размерами квот на закупки — для более эффективного закрытия потребностей проектных офисов.
Мне необходимо принимать управленческие решения и поэтому я пользуюсь построением модели управленческого учёта на будущее. Т.к. в зоне моей ответственности рентабельность всего производства, то моделирование и понимание того как какая-то закупка окажет влияние на тот или иной юнит и проект — необходимый критерий для принятия решения.
Чьими руками делать расчёты гипотетических моделей на постоянной основе — не играет никакой роли. Может это считать бухгалтер/кост менеджер или кто-либо другой.
Смысл данного кейса — показать как это считается и какое влияние может оказывать.
И в итоге эти две цифры пересчитываются бухгалтерами каждый год, закладываются в управленческий учет, и считаются в проектах.
Такой подход используем только для расчёта ставок, они как раз каждый год пересчитываются. Но это никак не поможет принять сейчас верное управленческое решение основанное на цифрах. Например, нужно вам принять решение о смене офиса, как вам поможет для принятия этого решения что бухгалтер учёл стоимость аренды текущего офиса?
В статье описан кейс работы с моделью управленческого учёта в компании AGIMA, ни в коем случае ни на какое новшество не претендует. Хотелось только формализовать и кратко зафиксировать опыт работы с таким базовым инструментом для управления разработкой, т.к. на нашем рынке — многие, к сожалению, до сих пор ведут управленческий учёт по поступлениям/расходам денежных средств.
возьмем, к примеру, скриншот описания вакансии из статьи — вы действительно считаете, что «опыт программирования от 3-х лет» и «знание Kotlin/Swift», это достаточно конкретное описание необходимого для вашей вакансии стека?
Вы абсолютно правы, но не учитываете нюанс нашей компании — мы заказная разработка. На данный момент у нас 65 проектов в активной стадии разработки и поддержки, тех стек совершенно разный, уровни необходимых специалистов от джунов (вчерашних школьников) до архитекторов.
Мы проверяли гипотезу увеличения количества более узких по стеку и задачам вакансий, но это сильно сужает (как вы заметили) входящую воронку соискателей. В добавок активностей в инфо поле приходится делать больше на каждую вакансию и время достижения такого же показателя конверсии уже на первом шаге воронки сильно увеличивается. Т.к. весь процесс подбора осуществляет внутренний штат сотрудников компании, которые получают фикс + косвенные на них, то общие затраты (создание вакансий, промо бюджет вакансий, фот сотрудников и тд) ещё в самом начале превышают условные «время и ресурсы на телефонное собеседование» в несколько раз. В последнем абзаце kamillaponka приводит показатель сокращения стоимости привлечения одного сотрудника и необходимое количество выходов в квартал, что бы такой подход был рентабелен. Так что совершенно не понял ваш довод.
благодарю, но мне нет дела до ваших вакансий, я просто выразил мнение того, что сейчас происходит на рынке, как это вижу я.
Я понимаю, что у каждого есть своё мнение и человек изначально судит по себе.
Не рекламы ради, предложение посмотреть наши вакансии родилось только из-за вашего безосновательного обвинения, что мы «хотим всезнайку за копейки» и не анализируем рынок ЗП. Это не так, смотрите пожалуйста пруф.
Или хотя бы наше исследование habr.com/ru/company/agima/blog/339216
Вы хотите заработать денег, трудоустраивая специалистов, ищите «крутых», но сами при этом редко соответствуете тому же уровню, увы.
Я не HR.
Если говорить про HR, то я не понимаю как они могут соответствовать абсолютно каждому портрету специалиста, которого они рекрутят. Абсурд же.
Это такая же профессия как и любая другая со своими уровнями грейдов и тонкостями задач: от прокачки hr бренда, промышленного сбора команд под ресурсную стратегию проекта до обычных агрегаций «холодных» подборок на HH.
Команда должна соответствовать и только она принимает решение о подготовке офера и условиях в нём.
Спасибо за ваш комментарий. Интересно услышать критику.
Всё что вы предлагаете — мы активно используем в том или ином виде, подтверждение тому — успешные кейсы по закрытию сложных вакансий за очень короткий период времени. Посмотрите хотя бы наш кейс 2018 года про набор мобильной команды на один очень большой ретейл проект.
То что вы приводите как пример — лишь крупица описаний из огромного количества успешно закрытых вакансий. Мы ни в коем случае никого не учим, для этого специально есть «Дисклеймер» в статье, тк описанные методы работают только в определённом сеттинге и в определённое время.
Действительно формируем гипотезы и проверяем их, об этом мы и хотели рассказать в статье.
Добрый день.
Мы постоянно занимаемся анализом ЗП по рынку и предлагаем зарплаты чуть выше этого рынка, поэтому ваша гипотеза не про нас.
Можете ознакомиться с нашими вакансиями.
В статье явно написано, что мы понимаем под «кадровым голодом» и откуда эта проблема взялась.
Речь исключительно про соотношение между количеством вакансий и количеством кандидатов на рынке труда с соответствующим тех стеком. Но если вы в этом сомневаетесь, то посмотрите пожалуйста аналитику по этому вопросу.
Не знаю каким площадкам лично вы доверяете, но такую аналитику по рынкам РФ вполне можно найти на том же РБК.
В целом гибкие методики скорее применимы когда нет точного понимания по конечному продукту и надо проверять бизнес гипотезы и подтверждать их количественными показателями. В других случая — в сравнение с водопадом, например, они будут в разы дороже, а речь всё-таки про коммерческую разработку где часто надо сэкономить бюджет заказчика.
К тому же, я считаю что есть необходимость и при использовании фреймворков гибких методологий, планировать и прогнозировать каждую итерацию разработки версии продукта для принятия тех или иных управленческих решений.
Если всё утрировать и обсуждать разработку сложного приложения в вакууме по гибким методологиям, то при наличие дорожной карты по фичам в разрезе версий — диаграммой Гантта, имхо, лучше всего планировать именно итерацию разработки версии. Версия содержит эпики, эпики в свою очередь спринты, спринты несколько стримов. При адекватной и устоявшейся команде разработки почти все риски являются явными на момент планирования итерации версии продукта, что позволяет достаточно точно определить критический путь этой итерации.
Диаграмма Гантта — это не про то, как точно определить даты дедлайнов. Это про то, как зафиксировать абсолютные контрольные точки по пути решения и далее уже работать с минимизацией рисков и другими параметрами проекта. Ресурсы, бюджеты и даты — всё относительно на Гантте, а вот майлстоуны — абсолютны!
Прошу прощения, но в статье уже содержится ответ на ваш вопрос в предпоследнем абзаце.
Предугадать все сроки никогда нельзя, но управлять требованиями, рисками, бюджетом и контрольными точками по продукту — вполне. Без предварительного тайм-плана это будет в разы менее эффективно. И чем более реален предварительный план — тем больше шансов на успех.
Данная практика была проверена на достаточно большом количестве действительно сложных и крупных проектов, но конечно же не может являться панацеей ;)
Спасибо за позитивную обратную связь.
Выгружайте план-график в html из Merlin и на хостинг — никакой эксель тогда не нужен, тк таймплан всегда должен быть актуален!
Спасибо за ваш комментарий.
Ещё раз пожалуйста прочитайте формализацию понятий «внутренний» и «внешний» тайм-планы.
Если вы можете за все неявные риски на моменте оценки в последствии костить клиента — это отлично. Но в действительности должен ли любой крупный клиент за вас сам закладывать риски в годовой бюджет на разработку?
И, кстати, «по себестоимости», наверное, это не про бизнес ;)
Более того в данной серии статей я рассказывал о 2500 человеко-часов в месяц только со стороны веб-продакшена (подрядчика), а не всей команды проекта.
В таких проектах принимает участие огромное количество человек: бизнес подразделения (как правило до 10 — каждый представляет свой продукт), маркетинг, представители IT департамента, управление информационной безопасности, люди из департамента электронной коммерции/digital, а так же другие подрядчики этого клиента. С ними со всеми приходится коммуницировать при разработке таких проектов (об этом я кстати и писал в статье).
1. В основном подключаем на небольшие задачи по разработке. Как правило это могут быть: контентные страницы/блоки, лендинги, формы обратной связи и т.д. Задачи с интеграциями стараемся не отдавать на внешних сотрудников.
Весь код обязательно пристально валидируется: перед работой мы раздаём наши чек-листы, по которым проходит приёмка + проводится код-ревью.
2. Да, проблема не сколько со скоростью вхождения в проект, сколько в целом с уровнем компетенций у внешних сотрудников.
Всегда закладываем дополнительные риски при планировании задачи на аутсорс.
Также делаем детальный тайминг с контрольными точками и стараемся не оставлять внешних сотрудников без присмотра более чем на 16 рабочих часов. Т.е. всегда есть промежуточные срезы.
Вообще относительно нашего взаимодействия с внешними командами/сотрудниками в ближайшие пару недель выйдет моя статья на другом информационном ресурсе. Stay tuned.
PO, в рамках конкретной задачи на проекте, начинает общаться с заказчиком напрямую и раньше чем эта задача попадёт к PM'у и первой линии.
Т.е. PO придумывает какую-то классную фичу и обсуждает её с заказчиком, после чего подключает PM'а и всех необходимых специалистов для оценки стоимости и сроков.
Как только заказчик подтверждает необходимость реализации данной задачи, то PO передаёт производство на сторону PM'а и первой линии, а сам только оказывает авторский надзор над продуктом (консультирует внутреннюю команду по задаче, осуществляет приёмку промежуточных результатов внутри, помогает «защищать» эти промежуточные результаты перед заказчиком и т.д.).
Это одна из особенностей заказной разработки. К сожалению, заказчики не всегда дают продумывать проект и вектор его развития на 100%. А иногда просто бюджет не позволяет и надо с чего-то начинать.
Но данная статья о совсем других заказчиках и проектах.
Мы стараемся максимально детализировать все предстоящие работы и прозрачно аргументировать клиенту необходимость каждого этапа, объясняя последствия отказа от определённой роли на проекте. Тот кто уже «обжигался» обычно понимают гораздо быстрее.
Кост мы формируем постепенно исходя из бизнес-задач клиента. Кому-то совершенно не нужны функциональные тесты и мониторинг доступности с системой оповещения, например. А для кого-то это критично и они понимают за что платят.
Т.е. у нас проект обычно стартует как набор небольших заказов, а далее он уже развивается до «гиганта». Самый молодой из «гигантских» проектов у нас сейчас около 2х лет находится в активной стадии поддержки и разработки. Самый старый — уже 6 лет.
Также у нас есть практика, когда мы прописываем определённые KPI в договоре и при их достижении мы получаем прибыль. Клиенты идут на такие договорённости гораздо более смело, но тут необходимо быть уверенным в качестве своих услуг.
— финансовую отчётность ведём, отдельно не описывал, в статье обозначал что всё что связано с «потоками денежных средств» вынесено за этот кейс;
— квартальные планы, конечно же, ведём. Строим модель на год, она в двух вариантах: «прогнозная» (цель) и «плановая» (от реального роста клиента и новых совершённых продаж), далее горизонт планирования 3 месяца по этим моделям (обновляются обе) ежемесячно. Т.е. каждый след месяц — «план», два последующих — «прогноз». Так называемый «тех долг» по «прогнозной» модели размазываем на след кварталы до конца года (от этой модели ставятся OKR и KPI команде), при этом по «плановой» ведём фактическое сжигание объёмов для статистики только.
В остальном очень полезно, изучу и подумаю о внедрении.
Чем больше компания — тем меньше на неё могут повлиять риски от несовпадения управленки и бухгалтерии, можно позволить менее точечно контролировать расхождения и допускать погрешности. Тем более вы говорите о большой компании и всего тысячах евро расхождения.
Но тем не менее даже крупные компании стремятся погрешность минимизировать «в пределах 5%» и это ну совсем не «от слова никак» ;)
У нас компания до 200 человек и мы уделяем много внимания полному совпадению бумаг и приходов/расходов. Да это очень сложно, при том что зачастую клиенты хотят и переплатить вперёд до актов (из-за того что у них годовые бюджеты) и надо морочиться с амортизацией по группам закупок и т.д. Зато риски минимизированы. А так — каждый сам принимает решение какая вероятность наступления этих рисков и их степень влияния на его компанию.
Мы заказная разработка, на данный момент у нас более 65 проектов в активной стадии разработки (веб или мобильные приложения) с совершенно разными тех стеками. Из-за особенностей заказной разработки приходится быстро масштабироваться в том числе и на короткосрочные проекты заказчиков. Поэтому приходится тюнить процессы рекрутинга и управлять на коротком горизонте планирования (3 месяца) приоритетами и размерами квот на закупки — для более эффективного закрытия потребностей проектных офисов.
Мне необходимо принимать управленческие решения и поэтому я пользуюсь построением модели управленческого учёта на будущее. Т.к. в зоне моей ответственности рентабельность всего производства, то моделирование и понимание того как какая-то закупка окажет влияние на тот или иной юнит и проект — необходимый критерий для принятия решения.
Чьими руками делать расчёты гипотетических моделей на постоянной основе — не играет никакой роли. Может это считать бухгалтер/кост менеджер или кто-либо другой.
Смысл данного кейса — показать как это считается и какое влияние может оказывать.
Такой подход используем только для расчёта ставок, они как раз каждый год пересчитываются. Но это никак не поможет принять сейчас верное управленческое решение основанное на цифрах. Например, нужно вам принять решение о смене офиса, как вам поможет для принятия этого решения что бухгалтер учёл стоимость аренды текущего офиса?
Да, с документом знаком.
Спасибо вам за рекомендацию и комментарий.
Вы абсолютно правы, но не учитываете нюанс нашей компании — мы заказная разработка. На данный момент у нас 65 проектов в активной стадии разработки и поддержки, тех стек совершенно разный, уровни необходимых специалистов от джунов (вчерашних школьников) до архитекторов.
Мы проверяли гипотезу увеличения количества более узких по стеку и задачам вакансий, но это сильно сужает (как вы заметили) входящую воронку соискателей. В добавок активностей в инфо поле приходится делать больше на каждую вакансию и время достижения такого же показателя конверсии уже на первом шаге воронки сильно увеличивается. Т.к. весь процесс подбора осуществляет внутренний штат сотрудников компании, которые получают фикс + косвенные на них, то общие затраты (создание вакансий, промо бюджет вакансий, фот сотрудников и тд) ещё в самом начале превышают условные «время и ресурсы на телефонное собеседование» в несколько раз. В последнем абзаце kamillaponka приводит показатель сокращения стоимости привлечения одного сотрудника и необходимое количество выходов в квартал, что бы такой подход был рентабелен. Так что совершенно не понял ваш довод.
Я понимаю, что у каждого есть своё мнение и человек изначально судит по себе.
Не рекламы ради, предложение посмотреть наши вакансии родилось только из-за вашего безосновательного обвинения, что мы «хотим всезнайку за копейки» и не анализируем рынок ЗП. Это не так, смотрите пожалуйста пруф.
Или хотя бы наше исследование habr.com/ru/company/agima/blog/339216
Я не HR.
Если говорить про HR, то я не понимаю как они могут соответствовать абсолютно каждому портрету специалиста, которого они рекрутят. Абсурд же.
Это такая же профессия как и любая другая со своими уровнями грейдов и тонкостями задач: от прокачки hr бренда, промышленного сбора команд под ресурсную стратегию проекта до обычных агрегаций «холодных» подборок на HH.
Команда должна соответствовать и только она принимает решение о подготовке офера и условиях в нём.
Спасибо за ваш комментарий. Интересно услышать критику.
Всё что вы предлагаете — мы активно используем в том или ином виде, подтверждение тому — успешные кейсы по закрытию сложных вакансий за очень короткий период времени. Посмотрите хотя бы наш кейс 2018 года про набор мобильной команды на один очень большой ретейл проект.
То что вы приводите как пример — лишь крупица описаний из огромного количества успешно закрытых вакансий. Мы ни в коем случае никого не учим, для этого специально есть «Дисклеймер» в статье, тк описанные методы работают только в определённом сеттинге и в определённое время.
Действительно формируем гипотезы и проверяем их, об этом мы и хотели рассказать в статье.
Мы постоянно занимаемся анализом ЗП по рынку и предлагаем зарплаты чуть выше этого рынка, поэтому ваша гипотеза не про нас.
Можете ознакомиться с нашими вакансиями.
В статье явно написано, что мы понимаем под «кадровым голодом» и откуда эта проблема взялась.
Речь исключительно про соотношение между количеством вакансий и количеством кандидатов на рынке труда с соответствующим тех стеком. Но если вы в этом сомневаетесь, то посмотрите пожалуйста аналитику по этому вопросу.
Не знаю каким площадкам лично вы доверяете, но такую аналитику по рынкам РФ вполне можно найти на том же РБК.
В интервью я говорил о интеграционной шине (ESB).
Спасибо что заметили, вы абсолютно правы!
К тому же, я считаю что есть необходимость и при использовании фреймворков гибких методологий, планировать и прогнозировать каждую итерацию разработки версии продукта для принятия тех или иных управленческих решений.
Если всё утрировать и обсуждать разработку сложного приложения в вакууме по гибким методологиям, то при наличие дорожной карты по фичам в разрезе версий — диаграммой Гантта, имхо, лучше всего планировать именно итерацию разработки версии. Версия содержит эпики, эпики в свою очередь спринты, спринты несколько стримов. При адекватной и устоявшейся команде разработки почти все риски являются явными на момент планирования итерации версии продукта, что позволяет достаточно точно определить критический путь этой итерации.
Диаграмма Гантта — это не про то, как точно определить даты дедлайнов. Это про то, как зафиксировать абсолютные контрольные точки по пути решения и далее уже работать с минимизацией рисков и другими параметрами проекта. Ресурсы, бюджеты и даты — всё относительно на Гантте, а вот майлстоуны — абсолютны!
Предугадать все сроки никогда нельзя, но управлять требованиями, рисками, бюджетом и контрольными точками по продукту — вполне. Без предварительного тайм-плана это будет в разы менее эффективно. И чем более реален предварительный план — тем больше шансов на успех.
Данная практика была проверена на достаточно большом количестве действительно сложных и крупных проектов, но конечно же не может являться панацеей ;)
Выгружайте план-график в html из Merlin и на хостинг — никакой эксель тогда не нужен, тк таймплан всегда должен быть актуален!
Ещё раз пожалуйста прочитайте формализацию понятий «внутренний» и «внешний» тайм-планы.
Если вы можете за все неявные риски на моменте оценки в последствии костить клиента — это отлично. Но в действительности должен ли любой крупный клиент за вас сам закладывать риски в годовой бюджет на разработку?
И, кстати, «по себестоимости», наверное, это не про бизнес ;)
Задача сложная, но такие возможности действительно есть!)
Постараемся в одной из следующих статей.
В таких проектах принимает участие огромное количество человек: бизнес подразделения (как правило до 10 — каждый представляет свой продукт), маркетинг, представители IT департамента, управление информационной безопасности, люди из департамента электронной коммерции/digital, а так же другие подрядчики этого клиента. С ними со всеми приходится коммуницировать при разработке таких проектов (об этом я кстати и писал в статье).
Прошу прощения за долгую реакцию.
1. В основном подключаем на небольшие задачи по разработке. Как правило это могут быть: контентные страницы/блоки, лендинги, формы обратной связи и т.д. Задачи с интеграциями стараемся не отдавать на внешних сотрудников.
Весь код обязательно пристально валидируется: перед работой мы раздаём наши чек-листы, по которым проходит приёмка + проводится код-ревью.
2. Да, проблема не сколько со скоростью вхождения в проект, сколько в целом с уровнем компетенций у внешних сотрудников.
Всегда закладываем дополнительные риски при планировании задачи на аутсорс.
Также делаем детальный тайминг с контрольными точками и стараемся не оставлять внешних сотрудников без присмотра более чем на 16 рабочих часов. Т.е. всегда есть промежуточные срезы.
Вообще относительно нашего взаимодействия с внешними командами/сотрудниками в ближайшие пару недель выйдет моя статья на другом информационном ресурсе. Stay tuned.
Скорость загрузки десктопа 84 из 100.
https://developers.google.com/speed/pagespeed/insights/?url=www.agima.ru&tab=desktop
Спасибо, мы в курсе и считаем такую оценку вполне приемлемой и удовлетворительной.
Статистику по сайтам наших конкурентов лучше не смотрите :)
Т.е. PO придумывает какую-то классную фичу и обсуждает её с заказчиком, после чего подключает PM'а и всех необходимых специалистов для оценки стоимости и сроков.
Как только заказчик подтверждает необходимость реализации данной задачи, то PO передаёт производство на сторону PM'а и первой линии, а сам только оказывает авторский надзор над продуктом (консультирует внутреннюю команду по задаче, осуществляет приёмку промежуточных результатов внутри, помогает «защищать» эти промежуточные результаты перед заказчиком и т.д.).
Но данная статья о совсем других заказчиках и проектах.
Мы стараемся максимально детализировать все предстоящие работы и прозрачно аргументировать клиенту необходимость каждого этапа, объясняя последствия отказа от определённой роли на проекте. Тот кто уже «обжигался» обычно понимают гораздо быстрее.
Кост мы формируем постепенно исходя из бизнес-задач клиента. Кому-то совершенно не нужны функциональные тесты и мониторинг доступности с системой оповещения, например. А для кого-то это критично и они понимают за что платят.
Т.е. у нас проект обычно стартует как набор небольших заказов, а далее он уже развивается до «гиганта». Самый молодой из «гигантских» проектов у нас сейчас около 2х лет находится в активной стадии поддержки и разработки. Самый старый — уже 6 лет.
Также у нас есть практика, когда мы прописываем определённые KPI в договоре и при их достижении мы получаем прибыль. Клиенты идут на такие договорённости гораздо более смело, но тут необходимо быть уверенным в качестве своих услуг.