5 лет провел на ютреке. Отличный продукт имхо значительно удобнее джиры вообще во всем, ну, кроме плагинов: юзабилити проще, процессы круче, кастомизация процессов проще или также (js скриптами создавать правила - отлично), аналог jql удобнее. После него вернулся на джиру - плевался.
короч, у вас проблема миграции - оно и ясно. А где их нет )
я не спорю, я как раз подтвержу про спецназ. Я лично работал с такими командами и это был кайф. Но в любой разработке продукта наступает момент, когда кавалерийский наскок надо заменять на системную процессную промышленную разработку.
А суперкоманду бросать на другое новое и неизведанное.
Но если уже продолжать мысль то суперкоманда вообще не особо требует методологии. Они как правило сами скажут, как часто будут выдавать, сами скажут, что надо на вход и, кстати, отчитываться для них тоже не проблема.
Так что скрам для меня - очередная красивая история от американцев. Но зерно логики в которой было и останется. Как оно есть в пмбоке, в SAFe и во всем остальном. Просто голову надо включать и все.
понимаю. а нет такого хорошего KPI, мы за 5 лет экспериментов не нашли.
Можно строить на отгруженном обьеме, но тогда станет выгодно его завышать
Можно на качестве и попадании в оценки но тогда а) разработка договаривается с тестированием что было меньше багов, б) начинаются абсурдные требования к докам в) завышения оценок (чтобы попадать)
Можно на успехе проекта, но некоторые проекты стратегические или просто длинные, успеха ждать надо год. Далеко не все готовы быть в роли предпринимателя и год получать , типа 150, чтобы потом получить 1,5 млн (и только в случае успеха). Да и кто решит, успех или нет и что считаем успехом - там тоже вопросики :)
У нас было для разработчиков так: есть фикса тыщ на 10 ниже рынка. И есть премия, которая делится на три (кажется) части и которую может получить разраб
исполнительская дисциплина (это аккуратный перенос задач из спринта в спринт, чтобы в прошлом они не терялись)
возвраты
отработанные полезные часы по трекеру - не менее 32
итог мне нравится: разработчики сами приходят, если нет работы, стараются проверять тикеты перед закрытием сами и сами просят переносить таски в конце недели. За это суммарно пацаны получали типа +30-40 тыщ сверху
Революция всегда кончается реакцией не просто так. Про Робеспьера помним, про Троцкого тоже. В мире айти все не так жестоко, но забавно, что сам революционер предал свои же идеалы, как только оброс жирком и столкнулся с разработкой энтерпрайз уровня.
Одно дело - продажи продавать, да идеи толкать с трибуны, другое - спуститься с небес и попробовать, как оно может работать в реальности.
Для меня СКРАМ как он был заявлен в манифесте, всегда выглядел мертворожденной игрушкой, которая нужна или небольшому стартапу, где "мы все одна семья" и пока еще есть инвестбабки на эксперименты или продукту, который не считает деньги.
А впрочем, продукту тоже, оказывается надо считать бабки )
А давайте я порассуждаю по второй части и синьоров Васю и Петю.
Если, при прочих равных, Петя по трекеру нарушает оценку в 50% случаев на 50% (к примеру), то его цена будет на 25% выше, чем Васи.
Выразится это в стоимости привлечения его на мой проект. У меня, как у РП, будет выбор: взять Васю за 4000/час, который попадет в сроки, которые даст или Петю, который не попадет и будет стоить в итоге 5000/час (он сделает объем за бОльший срок).
Чем не метрика? И основывать ее надо как раз на планфакте. Это вполне импакт - то есть влияние на проект/продукт
Да, узнав про такое (как Петя разработчик), я начну умножать оценки на 2 (и условный Петя именно так и поступал), но тут лечится адекватным РП или Техдиром или лидом, который проводят беседу об адекватности. Далее Петя идет учиться попадать в разумные оценки. Это полностью аналогично, как я провожу разговоры с офигевшими от страха аналитиками и РП.
Про ведущего разработчика Лешу, который ошибка найма - тоже отлично система работает, мы такого ровно год назад взяли. Выгнали с испыталки, когда он на онбоардинг взял неделю и не смог четко рассказть по дням, что он делал, а потом продолбал задачу на создание архитектуры (оценки, которую сам дал) и декомпозиции задач (тоже сам дал).
Чем не KPI? И опять таки: списание позволило поглядеть направление его мыслей в ходе пристрелочных пары недель, мы еще созванивались и помогали чуваку, не топили. Сам утонул. Итого: попадание в оценки не должно прямо влиять на зп, но как косвенная метрика использоваться должно.
Второе и более четкое по аналитике и разработке - возвраты. Для аналитиков - возвраты на доработку из разработки/QA и тоже самое по разработке.
Да, это потребует хорошей документации, селяви. Она должна быть.
Если вернуться к начальной точке: а что делать разработчику Васе, который умеет работать быстро и без ошибок и хочет получать х2 к текущей зарплате?
ответ 1 из 2х: если компания хорошая и отношения доверительные, рассказать, что он может работать быстрее и брать задачи сложнее, если это (можно и по факту испыталки) оценят. Далее стороны пробуют-смотрят - профит.
если компания плохая то: а) нафиг там вообще сидеть, сложно место сменить чтоли б) сказать что хочешь работать по выходным, делать код в будни а коммитить в выхи. Или просто работать на 2х работах, что тоже самое
принимаются. но редко. и, скорее, в небольших компаниях, которые считают время и деньги. В крупных менеджеры заняты получением премий и им уже пофигу, кто и как работает (
Зачем написана была эта статья: до сих по 50% компаний не учитывают нормально время сотрудников. Оно учитывается в экселях или аналогах. И это именно то, о чем коллега выше пишет - у них на бумажке все, типа, красиво, а реально разработка недозагружена до 50% (а то и больше).
Итог - компания недозарабатывает 50% денег и, что важно: сами разработчики недозарабатывают! Потому уже входит в тренд постепенно работа на фулл тайм в двух компаниях (нет ну а фигли, если время есть).
чтобы вы понимали: когда у меня один разраб начал вот так шакалить, мы его за 2 недели вычислили. Он очень сожалел, а мы пояснили, как ему надо работать у нас, чтобы получать больше. И он до сих пор работает (год с тех пор) и получает хор зп.
Короче. Меня самого печалит ситуация, сложившаяся в больших компаниях. Но это шанс для небольших и эффективных :)
Что, если сотрудник на фрилансе не хочет играть в глупые игры и хочет работать больше и получать больше? Ответ: повысить ставку и закрывать задачи быстрее. Если при этом он на фрилансе не сможет это продать - это вопрос не к исполнению, а к продажам.
Что если сотрудник работает в компании? Ответ: закрывать задачи раньше и просить еще работы у менеджера. Ах нет работы? Идти к линейному и жаловаться, что недозагружен. Сделать это несколько раз. Если всем плевать - это гнилое место и из него надо уходить. Но, как правило, дают ченить прикольное. Или переводят на более сложные проекты.
Теперь про 8 часов Васи != 8 часов Пети. Очевидно, что тут должна быть разница в ставке. И она есть, потому что Вася и Петя получают разные зарплаты. Итого, если Вася в 2 раза быстрее и в 1.5 раза дороже - мне выгоднее Вася. Если разницы нет - сроки решат, но скорее люди (не я, но такова увы практика, выберут подешевле). Это вам ответ из пункта один: если Вася хочет тратить 5 часов на работу, остальное на жизнь - да кто мешает то? Пусть продает себя дороже, если сможет. Это не вопрос учета времени.
Теперь не про фриланс, а про работу, где по ТК надо работать 8 часов. И за это платят зп. Если Вася не хочет работать 8 часов - пусть делает за 5 часов работу на 8. При этом, получая зп условного миддла. Если три часа при этом он будет отдыхать, я не буду против - его ставка невысокая, стоимость невысокая, скорость средняя. Но я стану против, если Вася попросит поднять зп. Потому что синьору платится зп выше процентов на 30 потому что от него ожидается производительность выше.
Теперь про следующий ваш вопрос (он очевидно напрашивается): как оцениваем производительность? Если в часах, это тупо приведет к завышению. Ответ: до конца это оцифровать невозможно. Тут для меня есть человеческий фактор: оценку исполнителя надо иногда проверять. Проверять может лид, РП, СТО - можно делать по разному. Исполнитель и РП должны друг другу доверять. Вот тогда это успешно работает, создавая баланс: исполнители не завышают оценки, если у них адекватные руководители.
У вас нет корреляции перфоманса на зп - кто сказал что нету? Механик тут несколько. К ним есть вопросы, но применяя их с поправкой на п5 выше, можно делать прикольные штуки:
премия по итогам выполненных задач (без возвратов и просрочек)
премия по итогам задач без возвратов (просрочки исключаем, тк ведут к завышениям)
премия по итогу успеха проекта/достижения целей, если попадал в оценки + нет возвратов + высокая оценка от команды.
тут поиграть можно. Да, спорить тоже можно, но механики есть. Тем более с учетом п3.
Подводя итог: наш спор упрется в термин "производительность исполнителя" и надо понимать что это величина только отчасти оцифровывается, так как наши проекты и работы - это не стройка, а , по сути НИОКРы, новая деятельность. Поэтому в любой оценке должен быть человеческий фактор.
Где этого не учитывают - там присуствует описанная вами ситуация. Где учитывают - там вытроен отличный процесс.
На последнем месте у нас команда работала именно так и сами ребята разработчики очень уважали процессы, которые их защищали в части переработок и справедливой оценки по работе.
это классическое возражение, мне есть, что на него ответить.
Я работаю в командах разработки 25 лет, я поработал в большом количестве коллективов, где был исполнителем, лидом, РП, руководителем РП.
Большинство исполнителей относятся нормально к учету сделанной работы, особенно если видят, что
до оценки детально не докапываются и есть доверие
если оценка нарушается, человека не обвиняют во всех грехах и срыве проекта
Про этоже я и написал (и не только я): если в команде если доверие, механизм оценок и списаний отлично работает. В вашем примере (а у меня аналогичных тоже много) мне будет пофигу, что фрилансер делает работу за 5 часов, списывая 10. Потому что
а) меня по срокам устраивает
б) меня по бабкам устраивает.
на этом все. И я знаю, что он знает, что я знаю, что он дает с запасом. А я иду на встречу, доверяя ему, иногда давая послабления и тп. Но когда уже у меня будет жопа, он впишется на 100% и поможет уже мне, как я ему до этого. И вот такая команда работает отлично.
Это как раз тот момент, который крайне сложно оцифровать, а может быть и невозможно. И тут должны работать руководители. В вашем примере - его заказчики оказались нормальными ребятами, которые поняли, что результат устраивает и смягчили учет времени.
НО.
это не отменяет необходимости учета в большой компании. Потому что с некоторой точки - это просто необходимость. История, как всегда в поиске баланса: жесткий учет - это зло, отсутствие учета - тоже зло.
Требования заказчиков не должны иметь отношения к внутреннему учету и управлению производством, потому никак не влияют на внутренний учет. Ответ выглядит отпиской ((
Учет фактических затрат лично РП проекта, это еще хуже, коллеги. Итог - у вас иллюзия 100% утилизации, а по опыту, там 30-50% времени народ балду пинает (РП задач не поставил, заказчик тормозит и тп). А ведь можно дать пинка и ускорить. Или перевести часть команды на другие проекты. Это от 20 до 50% экономия по ФОТ. При вашем ФОТ - миллиарды экономии.
Нет, не так. Фактические затраты разработки учитываются в трекере всегда. Фиксированные затраты учитываются отдельно в ИСУП. Ответ выглядит отпиской ((
Согласен, отчетность перед клиентом слишком разная. Поэтому она не должна иметь отношения к управленческой отчётности у вас в компании, об этом и написано выше. Автоматически должен происходить сбор управленческой отчетности для РПО/СЕО, чтобы они понимали точки воздействия на систему.
Чтобы не выглядеть пустословом: я лично сделал более 100 проектов разного размера и формата, я настраивал процессы проектных офисов от 30 до 400 разработчиков и отлично понимаю предмет разговора.
Докопался до вас не из вредности, а из любви к компании IBS, где сам когда то мечтал работать. Грустно видеть, что у вас вот так.
Если интересно - почитайте мой профиль, мои статьи (на Хабре все есть). Можем поговорить детальнее, я покажу точки роста. Если вы сэкономите 10% от ФОТ - это уже будет очень много денег. А это и есть чистый смысл lean подхода: больше эффективности и протока на тех же ресурсах.
спасибо. не, я как раз очень хочу увидеть критику. Потому что на основании моего опыта выкристаллизовался именно этот подход. Именно его я пробовал последние 5 лет на команде 100 человек и получил просто отличные операционные результаты .
Причем я его тестировал и в других командах (продуктовая и внутреннее ИТ), до 400т человек и там тоже было хорошо.
Допускаю, что это не панацея, но я хочу понять. где изъян?
Да, многие отвечают: сложно приучить команду к списаниям, если не списывались никогда (особенно 400 человек сразу). Это ясный аргумент.
Да, многие говорят, что на таком учете данные не до конца точные все равно, но для целей управления - более чем. Там шикарнейшая модель EVM получается , да еще и в реальном времени.
спросил уже в телеге, спрошу и тут (пусть тоже народ каменты почитает, полезно): и как же это делать? Я понимаю, о чем написано по ссылке и я на последнем месте работы вышел , фактически, на 4й уровень согласно автору, но.
Контроль никто не отменял. И по ссылке нигде не сказано, что данные собирать не нужно. Вы же врядли предлагаете перестать собирать первичку для принятия решений? Или как?
PS: отдельно скажу: если есть проект, который представляет из себя конвеер однотипных задач, если ресурсы проекта не делятся с другими проектами, если команда проекта работает давно и постоянно и на нее можно положиться, я такое могу допустить. Но слишком много "если" получается.
Вот что бывает когда айтишники не глядя начинают оцифровывать не IT предприятие. Каждый, кто оцифровывал процессы, сталкивался с таким. Я сталкивался даже не 10 раз, а больше. Автор статьи встретился с этим впервые, а позже несколько изменил свое мнение, что видно из окончания этот статьи:
Поэтому я… Хотел сказать – скрепя сердце, но нет – с огромной радостью и облегчением! – добавляю проверенные элементы контроллинга в систему управления задачами, которую делаю. Сила ведь в интеграции, а не в противопоставлении. Это юношеский максимализм заставляет орать «Scum forever!» или «Дисциплина, и только дисциплина!». А я возьму лучшее – из первого и второго – и добавлю свое, наработанное за 10 лет практики управления задачами.
Вы знаете, я всегда за критику, но вы говорите о плохом менеджменте. хотя по факту статьи вы не сказали вообще ничего. По сути вы сделали ничем не подтвержденный переход на личности.
Если есть что сказать по сути проблемы - скажите, иначе не смогу поддержать дискуссию.
Я оценил вашу иронию, но, действительно, у меня есть канал для менеджеров на котором я не зарабатываю, а который я использую для обсуждения тенденций и проблем в управлении в ИТ. Ничего плохого в том, что я даю на него ссылки не вижу.
А вы по сути согласны или нет, расскажите, и почему?
хорошая история, ваш тезис я тоже и слышал, и читал тут, у нас на Хабре.
Давайте я попробую не оппонировать вам, а ответить, что я про это думаю. То есть именно в порядке обмена опытом.
Я, на основании личного опыта, умею оценивать проекты на несколько сотен млн рублей и попадать в оценку по фактическим трудозатратам с точностью до 0.5% (да, есть такой пример в жизни). Но я делаю это основываясь на неявных и неформализованных критериях, которые называются "Экспертная оценка". Формализовать в регламент это я не умею. Если умеете вы - поделитесь таким регламентом. Особенно с учетом того, что я тоже работаю в заказной разработке в куче разных областей и не вижу, как это поддается формализации. Очень интересно, правда
можно даже для интереса рассмотреть проект по созданию какой нить внутренней системы предприятия для обработки заявок, интегрированной с биллингом, HR системой и парочкой других, чтобы понять, а как вы формализуете ее оценку?
Я понимаю, что мы с вами можем вообще говорить о разном: говоря об оценке, я понимаю, что есть минимум три оценки, которые делаю в больших проектах я:
предварительная - на основании бизнес требований
уточненная - на основании уточненных требований, ограничений и допущений
детальная - на базе декомпозиции требований командой разработки
в этой парадигме оценка от исполнителей появится только в части 2 или 3. Но и в части 1 я считаю важным привлекать ответственного от техблока. Принципиально это важно, поскольку тогда разработчики несут ответственность за решение. Это именно делегирование ответственности в команду и командная игра. Да, менеджер может сделать все сам (тем более лучше выйдет), но это классика делегирования: один в поле по итогу воин хуже, чем команда. А когда команда или ТехДир или Лид дают оценки, они берут на себя часть ответственности за техническое решение, что есть правильно с тз оргструктуры проекта. Вы согласитесь или покритикуете такой подход?
Я так не считаю. Согласен в части "многие затраты непредсказуемы", но очень важно не потерять суть за частными проблемами: сложность планирования планирования не должна отменять. Зато если я оцениваю сам (а на высоком уровне я умею оценивать вполне), я не делегирую часть ответственности своей команде. Что позже может привести к проблемам посерьезнее: срыву сроков и ругани в команде. Я с таким сталкивался не раз, когда сейлзы продавали, а тех команда потом ругалась, почему не позвали на оценку проекта??
А расскажите как вы делаете именно, интересно? По пулу задач из трекера с усреднением или как то хитрее? И для каких проектов у вас это работает?
да уж куда там. по опросам до сих пор - самый популярный ИСУП это "самописная система", затем MSP, затем JIRA. На рынке полный бардак, что подтверждает результат опроса под статьей.
Я не просто знаю десятки вполне профессиональных РП, которые в глаза не видели PMBoK и при этом успешно внедряют, но и сам таким был долго.
PMBoK - просто справочник, который не дает ответа на обычные вопросы РП:
как затащить невозможное
как устранить хаос
как сделать так, чтобы заказчик был доволен
как выжить на проекте
Указанные книги стараются ответить именно на эти вопросы. Управление проектами вообще больше софтскилловая область, нежели хардовая. Невозможно хорошо делать проекты, прочитав ПМБоК. А вот делать хорошо проекты, не читая его - можно.
нет, оба для исполниетелей. JIRA пытаются натянуть на менеджеров с помощью плагинов но это как натягивать сову на глобус. Получается, но сове больно
5 лет провел на ютреке. Отличный продукт имхо значительно удобнее джиры вообще во всем, ну, кроме плагинов: юзабилити проще, процессы круче, кастомизация процессов проще или также (js скриптами создавать правила - отлично), аналог jql удобнее. После него вернулся на джиру - плевался.
короч, у вас проблема миграции - оно и ясно. А где их нет )
я не спорю, я как раз подтвержу про спецназ. Я лично работал с такими командами и это был кайф. Но в любой разработке продукта наступает момент, когда кавалерийский наскок надо заменять на системную процессную промышленную разработку.
А суперкоманду бросать на другое новое и неизведанное.
Но если уже продолжать мысль то суперкоманда вообще не особо требует методологии. Они как правило сами скажут, как часто будут выдавать, сами скажут, что надо на вход и, кстати, отчитываться для них тоже не проблема.
Так что скрам для меня - очередная красивая история от американцев. Но зерно логики в которой было и останется. Как оно есть в пмбоке, в SAFe и во всем остальном. Просто голову надо включать и все.
понимаю. а нет такого хорошего KPI, мы за 5 лет экспериментов не нашли.
Можно строить на отгруженном обьеме, но тогда станет выгодно его завышать
Можно на качестве и попадании в оценки но тогда а) разработка договаривается с тестированием что было меньше багов, б) начинаются абсурдные требования к докам в) завышения оценок (чтобы попадать)
Можно на успехе проекта, но некоторые проекты стратегические или просто длинные, успеха ждать надо год. Далеко не все готовы быть в роли предпринимателя и год получать , типа 150, чтобы потом получить 1,5 млн (и только в случае успеха). Да и кто решит, успех или нет и что считаем успехом - там тоже вопросики :)
У нас было для разработчиков так: есть фикса тыщ на 10 ниже рынка. И есть премия, которая делится на три (кажется) части и которую может получить разраб
исполнительская дисциплина (это аккуратный перенос задач из спринта в спринт, чтобы в прошлом они не терялись)
возвраты
отработанные полезные часы по трекеру - не менее 32
итог мне нравится: разработчики сами приходят, если нет работы, стараются проверять тикеты перед закрытием сами и сами просят переносить таски в конце недели. За это суммарно пацаны получали типа +30-40 тыщ сверху
Большинству механика нравилась
уф, я прочитал. Длинное конечно, я бы вынес tldr в начало ))
но очень спасибо за ликбез. Оказывается, блин, я внедряю эджайлом тайп Ц уже 10 лет. А я то думал, что я пенек старообрядческий.
Поучительная история про ребят, которые отлично продали всему миру красивую идею, породили новый рынок Эджайл-коучей, а потом сами переобулись.
Впрочем не буду и обесценивать: понятие Спринта как этапа, добавляющего ценность регулярно, пришло и осталось со мной уже видимо насовсем.
С последним тезисом и вовсе согласен: главное не методология, а понимание того как и зачем ее применять.
Революция всегда кончается реакцией не просто так. Про Робеспьера помним, про Троцкого тоже. В мире айти все не так жестоко, но забавно, что сам революционер предал свои же идеалы, как только оброс жирком и столкнулся с разработкой энтерпрайз уровня.
Одно дело - продажи продавать, да идеи толкать с трибуны, другое - спуститься с небес и попробовать, как оно может работать в реальности.
Для меня СКРАМ как он был заявлен в манифесте, всегда выглядел мертворожденной игрушкой, которая нужна или небольшому стартапу, где "мы все одна семья" и пока еще есть инвестбабки на эксперименты или продукту, который не считает деньги.
А впрочем, продукту тоже, оказывается надо считать бабки )
А давайте я порассуждаю по второй части и синьоров Васю и Петю.
Если, при прочих равных, Петя по трекеру нарушает оценку в 50% случаев на 50% (к примеру), то его цена будет на 25% выше, чем Васи.
Выразится это в стоимости привлечения его на мой проект. У меня, как у РП, будет выбор: взять Васю за 4000/час, который попадет в сроки, которые даст или Петю, который не попадет и будет стоить в итоге 5000/час (он сделает объем за бОльший срок).
Чем не метрика? И основывать ее надо как раз на планфакте. Это вполне импакт - то есть влияние на проект/продукт
Да, узнав про такое (как Петя разработчик), я начну умножать оценки на 2 (и условный Петя именно так и поступал), но тут лечится адекватным РП или Техдиром или лидом, который проводят беседу об адекватности.
Далее Петя идет учиться попадать в разумные оценки. Это полностью аналогично, как я провожу разговоры с офигевшими от страха аналитиками и РП.
Про ведущего разработчика Лешу, который ошибка найма - тоже отлично система работает, мы такого ровно год назад взяли. Выгнали с испыталки, когда он на онбоардинг взял неделю и не смог четко рассказть по дням, что он делал, а потом продолбал задачу на создание архитектуры (оценки, которую сам дал) и декомпозиции задач (тоже сам дал).
Чем не KPI? И опять таки: списание позволило поглядеть направление его мыслей в ходе пристрелочных пары недель, мы еще созванивались и помогали чуваку, не топили. Сам утонул. Итого: попадание в оценки не должно прямо влиять на зп, но как косвенная метрика использоваться должно.
Второе и более четкое по аналитике и разработке - возвраты. Для аналитиков - возвраты на доработку из разработки/QA и тоже самое по разработке.
Да, это потребует хорошей документации, селяви. Она должна быть.
Если вернуться к начальной точке: а что делать разработчику Васе, который умеет работать быстро и без ошибок и хочет получать х2 к текущей зарплате?
ответ 1 из 2х: если компания хорошая и отношения доверительные, рассказать, что он может работать быстрее и брать задачи сложнее, если это (можно и по факту испыталки) оценят. Далее стороны пробуют-смотрят - профит.
если компания плохая то: а) нафиг там вообще сидеть, сложно место сменить чтоли б) сказать что хочешь работать по выходным, делать код в будни а коммитить в выхи. Или просто работать на 2х работах, что тоже самое
принимаются. но редко. и, скорее, в небольших компаниях, которые считают время и деньги. В крупных менеджеры заняты получением премий и им уже пофигу, кто и как работает (
Зачем написана была эта статья: до сих по 50% компаний не учитывают нормально время сотрудников. Оно учитывается в экселях или аналогах. И это именно то, о чем коллега выше пишет - у них на бумажке все, типа, красиво, а реально разработка недозагружена до 50% (а то и больше).
Итог - компания недозарабатывает 50% денег и, что важно: сами разработчики недозарабатывают! Потому уже входит в тренд постепенно работа на фулл тайм в двух компаниях (нет ну а фигли, если время есть).
чтобы вы понимали: когда у меня один разраб начал вот так шакалить, мы его за 2 недели вычислили. Он очень сожалел, а мы пояснили, как ему надо работать у нас, чтобы получать больше. И он до сих пор работает (год с тех пор) и получает хор зп.
Короче. Меня самого печалит ситуация, сложившаяся в больших компаниях. Но это шанс для небольших и эффективных :)
Все верно. Идем дальше.
Что, если сотрудник на фрилансе не хочет играть в глупые игры и хочет работать больше и получать больше? Ответ: повысить ставку и закрывать задачи быстрее. Если при этом он на фрилансе не сможет это продать - это вопрос не к исполнению, а к продажам.
Что если сотрудник работает в компании? Ответ: закрывать задачи раньше и просить еще работы у менеджера. Ах нет работы? Идти к линейному и жаловаться, что недозагружен. Сделать это несколько раз. Если всем плевать - это гнилое место и из него надо уходить. Но, как правило, дают ченить прикольное. Или переводят на более сложные проекты.
Теперь про 8 часов Васи != 8 часов Пети. Очевидно, что тут должна быть разница в ставке. И она есть, потому что Вася и Петя получают разные зарплаты. Итого, если Вася в 2 раза быстрее и в 1.5 раза дороже - мне выгоднее Вася. Если разницы нет - сроки решат, но скорее люди (не я, но такова увы практика, выберут подешевле). Это вам ответ из пункта один: если Вася хочет тратить 5 часов на работу, остальное на жизнь - да кто мешает то? Пусть продает себя дороже, если сможет. Это не вопрос учета времени.
Теперь не про фриланс, а про работу, где по ТК надо работать 8 часов. И за это платят зп. Если Вася не хочет работать 8 часов - пусть делает за 5 часов работу на 8. При этом, получая зп условного миддла. Если три часа при этом он будет отдыхать, я не буду против - его ставка невысокая, стоимость невысокая, скорость средняя.
Но я стану против, если Вася попросит поднять зп. Потому что синьору платится зп выше процентов на 30 потому что от него ожидается производительность выше.
Теперь про следующий ваш вопрос (он очевидно напрашивается): как оцениваем производительность? Если в часах, это тупо приведет к завышению. Ответ: до конца это оцифровать невозможно. Тут для меня есть человеческий фактор: оценку исполнителя надо иногда проверять. Проверять может лид, РП, СТО - можно делать по разному. Исполнитель и РП должны друг другу доверять. Вот тогда это успешно работает, создавая баланс: исполнители не завышают оценки, если у них адекватные руководители.
У вас нет корреляции перфоманса на зп - кто сказал что нету? Механик тут несколько. К ним есть вопросы, но применяя их с поправкой на п5 выше, можно делать прикольные штуки:
премия по итогам выполненных задач (без возвратов и просрочек)
премия по итогам задач без возвратов (просрочки исключаем, тк ведут к завышениям)
премия по итогу успеха проекта/достижения целей, если попадал в оценки + нет возвратов + высокая оценка от команды.
тут поиграть можно. Да, спорить тоже можно, но механики есть. Тем более с учетом п3.
Подводя итог: наш спор упрется в термин "производительность исполнителя" и надо понимать что это величина только отчасти оцифровывается, так как наши проекты и работы - это не стройка, а , по сути НИОКРы, новая деятельность. Поэтому в любой оценке должен быть человеческий фактор.
Где этого не учитывают - там присуствует описанная вами ситуация. Где учитывают - там вытроен отличный процесс.
На последнем месте у нас команда работала именно так и сами ребята разработчики очень уважали процессы, которые их защищали в части переработок и справедливой оценки по работе.
это классическое возражение, мне есть, что на него ответить.
Я работаю в командах разработки 25 лет, я поработал в большом количестве коллективов, где был исполнителем, лидом, РП, руководителем РП.
Большинство исполнителей относятся нормально к учету сделанной работы, особенно если видят, что
до оценки детально не докапываются и есть доверие
если оценка нарушается, человека не обвиняют во всех грехах и срыве проекта
Про этоже я и написал (и не только я): если в команде если доверие, механизм оценок и списаний отлично работает. В вашем примере (а у меня аналогичных тоже много) мне будет пофигу, что фрилансер делает работу за 5 часов, списывая 10. Потому что
а) меня по срокам устраивает
б) меня по бабкам устраивает.
на этом все. И я знаю, что он знает, что я знаю, что он дает с запасом. А я иду на встречу, доверяя ему, иногда давая послабления и тп. Но когда уже у меня будет жопа, он впишется на 100% и поможет уже мне, как я ему до этого. И вот такая команда работает отлично.
Это как раз тот момент, который крайне сложно оцифровать, а может быть и невозможно. И тут должны работать руководители. В вашем примере - его заказчики оказались нормальными ребятами, которые поняли, что результат устраивает и смягчили учет времени.
НО.
это не отменяет необходимости учета в большой компании. Потому что с некоторой точки - это просто необходимость. История, как всегда в поиске баланса: жесткий учет - это зло, отсутствие учета - тоже зло.
Увы, это отписки.
По пунктам:
Требования заказчиков не должны иметь отношения к внутреннему учету и управлению производством, потому никак не влияют на внутренний учет.
Ответ выглядит отпиской ((
Учет фактических затрат лично РП проекта, это еще хуже, коллеги.
Итог - у вас иллюзия 100% утилизации, а по опыту, там 30-50% времени народ балду пинает (РП задач не поставил, заказчик тормозит и тп). А ведь можно дать пинка и ускорить. Или перевести часть команды на другие проекты.
Это от 20 до 50% экономия по ФОТ. При вашем ФОТ - миллиарды экономии.
Нет, не так. Фактические затраты разработки учитываются в трекере всегда. Фиксированные затраты учитываются отдельно в ИСУП.
Ответ выглядит отпиской ((
Согласен, отчетность перед клиентом слишком разная. Поэтому она не должна иметь отношения к управленческой отчётности у вас в компании, об этом и написано выше. Автоматически должен происходить сбор управленческой отчетности для РПО/СЕО, чтобы они понимали точки воздействия на систему.
Чтобы не выглядеть пустословом: я лично сделал более 100 проектов разного размера и формата, я настраивал процессы проектных офисов от 30 до 400 разработчиков и отлично понимаю предмет разговора.
Докопался до вас не из вредности, а из любви к компании IBS, где сам когда то мечтал работать. Грустно видеть, что у вас вот так.
Если интересно - почитайте мой профиль, мои статьи (на Хабре все есть). Можем поговорить детальнее, я покажу точки роста. Если вы сэкономите 10% от ФОТ - это уже будет очень много денег. А это и есть чистый смысл lean подхода: больше эффективности и протока на тех же ресурсах.
спасибо. не, я как раз очень хочу увидеть критику. Потому что на основании моего опыта выкристаллизовался именно этот подход. Именно его я пробовал последние 5 лет на команде 100 человек и получил просто отличные операционные результаты .
Причем я его тестировал и в других командах (продуктовая и внутреннее ИТ), до 400т человек и там тоже было хорошо.
Допускаю, что это не панацея, но я хочу понять. где изъян?
Да, многие отвечают: сложно приучить команду к списаниям, если не списывались никогда (особенно 400 человек сразу). Это ясный аргумент.
Да, многие говорят, что на таком учете данные не до конца точные все равно, но для целей управления - более чем. Там шикарнейшая модель EVM получается , да еще и в реальном времени.
Так почему никто не использует? :)
спросил уже в телеге, спрошу и тут (пусть тоже народ каменты почитает, полезно): и как же это делать? Я понимаю, о чем написано по ссылке и я на последнем месте работы вышел , фактически, на 4й уровень согласно автору, но.
Контроль никто не отменял. И по ссылке нигде не сказано, что данные собирать не нужно. Вы же врядли предлагаете перестать собирать первичку для принятия решений? Или как?
PS: отдельно скажу: если есть проект, который представляет из себя конвеер однотипных задач, если ресурсы проекта не делятся с другими проектами, если команда проекта работает давно и постоянно и на нее можно положиться, я такое могу допустить. Но слишком много "если" получается.
Спасибо, отличная история.
Вот что бывает когда айтишники не глядя начинают оцифровывать не IT предприятие. Каждый, кто оцифровывал процессы, сталкивался с таким. Я сталкивался даже не 10 раз, а больше. Автор статьи встретился с этим впервые, а позже несколько изменил свое мнение, что видно из окончания этот статьи:
Золотые слова, которых придерживаюсь и я.
Вы знаете, я всегда за критику, но вы говорите о плохом менеджменте. хотя по факту статьи вы не сказали вообще ничего. По сути вы сделали ничем не подтвержденный переход на личности.
Если есть что сказать по сути проблемы - скажите, иначе не смогу поддержать дискуссию.
Спасибо.
Я оценил вашу иронию, но, действительно, у меня есть канал для менеджеров на котором я не зарабатываю, а который я использую для обсуждения тенденций и проблем в управлении в ИТ. Ничего плохого в том, что я даю на него ссылки не вижу.
А вы по сути согласны или нет, расскажите, и почему?
хорошая история, ваш тезис я тоже и слышал, и читал тут, у нас на Хабре.
Давайте я попробую не оппонировать вам, а ответить, что я про это думаю. То есть именно в порядке обмена опытом.
Я, на основании личного опыта, умею оценивать проекты на несколько сотен млн рублей и попадать в оценку по фактическим трудозатратам с точностью до 0.5% (да, есть такой пример в жизни). Но я делаю это основываясь на неявных и неформализованных критериях, которые называются "Экспертная оценка". Формализовать в регламент это я не умею. Если умеете вы - поделитесь таким регламентом. Особенно с учетом того, что я тоже работаю в заказной разработке в куче разных областей и не вижу, как это поддается формализации. Очень интересно, правда
можно даже для интереса рассмотреть проект по созданию какой нить внутренней системы предприятия для обработки заявок, интегрированной с биллингом, HR системой и парочкой других, чтобы понять, а как вы формализуете ее оценку?
Я понимаю, что мы с вами можем вообще говорить о разном: говоря об оценке, я понимаю, что есть минимум три оценки, которые делаю в больших проектах я:
предварительная - на основании бизнес требований
уточненная - на основании уточненных требований, ограничений и допущений
детальная - на базе декомпозиции требований командой разработки
в этой парадигме оценка от исполнителей появится только в части 2 или 3. Но и в части 1 я считаю важным привлекать ответственного от техблока.
Принципиально это важно, поскольку тогда разработчики несут ответственность за решение. Это именно делегирование ответственности в команду и командная игра.
Да, менеджер может сделать все сам (тем более лучше выйдет), но это классика делегирования: один в поле по итогу воин хуже, чем команда. А когда команда или ТехДир или Лид дают оценки, они берут на себя часть ответственности за техническое решение, что есть правильно с тз оргструктуры проекта.
Вы согласитесь или покритикуете такой подход?
Я так не считаю. Согласен в части "многие затраты непредсказуемы", но очень важно не потерять суть за частными проблемами: сложность планирования планирования не должна отменять.
Зато если я оцениваю сам (а на высоком уровне я умею оценивать вполне), я не делегирую часть ответственности своей команде. Что позже может привести к проблемам посерьезнее: срыву сроков и ругани в команде. Я с таким сталкивался не раз, когда сейлзы продавали, а тех команда потом ругалась, почему не позвали на оценку проекта??
А расскажите как вы делаете именно, интересно? По пулу задач из трекера с усреднением или как то хитрее? И для каких проектов у вас это работает?
Это само собой)
да уж куда там. по опросам до сих пор - самый популярный ИСУП это "самописная система", затем MSP, затем JIRA. На рынке полный бардак, что подтверждает результат опроса под статьей.
Я не просто знаю десятки вполне профессиональных РП, которые в глаза не видели PMBoK и при этом успешно внедряют, но и сам таким был долго.
PMBoK - просто справочник, который не дает ответа на обычные вопросы РП:
как затащить невозможное
как устранить хаос
как сделать так, чтобы заказчик был доволен
как выжить на проекте
Указанные книги стараются ответить именно на эти вопросы. Управление проектами вообще больше софтскилловая область, нежели хардовая. Невозможно хорошо делать проекты, прочитав ПМБоК. А вот делать хорошо проекты, не читая его - можно.