Вообще, сбор статистики по метрикам среднего выполнения, отклонений и тп - безусловно интересная штука.
При этом отказ от оценок разработчиками ведет нас к паре интересных моментов
Разработчик не несет ответственности за сроки. С одной стороны, мы создаем комфортную среду для разработчика, с другой - снимаем с него ответственность за выполнение задачи. А ответственность - мера взрослости. Умение дать оценку и попасть в нее - это , по сути, менеджерский скилл. А менеджер, по Адзизесу - любой, кто дает срок на работу. То есть оценка задачи и последующее старание попасть в эту оценку создает стресс для работника, но в тоже время каждый раз делает его профессиональнее. Разговоры про искусственные завышения оценок валидны только если доверия в команде нет. Там ребята начинают страховаться. Но это претензия к РП, это не проблема исполнителей. Итого:
- оценка в часах помогает расти команде профессионально, обучаясь ответственности - оценка в часах позволяет выделить узкие места процесса (сотрудник) и , поговорив с ним, добавить в это место резервирование.
Может возникнуть соблазн (раз уж мы заботимся об исполнителях) вообще не учитывать время в трекере, потраченное на задачу. А вот тут последствия вообще могут быть печальными (некорректный учета факта)
если вам не надо обещать сроки - замечательно можно работать.
как сказала одна девочка РП из Яндекса на каком то тренинге: "вы знаете, наш best practice, это по возможности не давать никаких сроков заказчику, потому что все может поменяться.
А заказчики, паразиты, вечно просят определенности, все беды от них :)
Если серьезно, когда РП подписывается под срок реализации, он должен подписываться не сам (ибо он просто админ), а с командой. Вот тут каждый участник начинает отвечать за свою работу. И тут у каждого исполнителя персональная отвествтенность
Спасибо. Да, статья несерьезная. А, впрочем, вполне серьезная, потому что позволяет применить опыт компромиссов, формирования ожиданий и на работе и в личных отношениях. Да и вывод тут важный: отношения заканчиваются, это вообще нормально. Важно сделать выводы и так, как косячил, больше не делать. И в следующий раз будет лучше. А если выводы не сделать, будет также. Я считаю, для работы это важно - рефлексия и исправление ошибок - часть профессионального роста.
А минусят за неправильные хабы, похоже, но я искренне не понимаю, чего неправильного, хабы именно те, что надо :)
спасибо. в целом не вижу сильных отличий от стандартной разработки:
вы делаете план работ в Мерлине (а ктото в проджекте). Чем ваш подход лучше общего на рынке?
вы делаете декомпоз работ и осаживаете его на трекер (задачи). Вы делаете в своей системе (как я понял), а большинство - в JIRA (и JIRA гибче вашей системы). Чем ваш подход лучше?
Все остальное - детали и метрики, специфичные для кажой компании.
И кстати, вопрос 3 - вы помянули, что сократили time-to-market. А как считали сокращение, расскАжите?
Приехал в Аус по работе - и я понял, что сказать ничего не могу. Только практика, только хардкор. А правило зеленой ручки относится не только к английскому - оно вообще про перфекционизм (да чтоп ему повылазило).
как человек, который учил английский в школе с 5го класса (твердое 4)
как человек который учил в институте (4 и зачет)
как человек который учился на курсах (5, разумеется)
а потом приехал по работе в Австралию и не понял нихрена и связать 2х слов не смог. А через полгода спикал только в путь даже с небольшим вокабуляром. Просто перестал париться про акцент и это наше вечное "как сказать правильно".
Статья в точку. А то что автор рекламирует в конце - и чего такого? Контент годный, опыт у чувака есть.
тут можно делать по-разному. Если приоритет везде равный, это, по умолчанию, означает, что порядок - на усмотрение производства. Если есть менеджер, то на его усмотрение (обычно он все таки есть).
Если менеджера нет и есть желание сделать полностью автоматический конвеер... ну я аккуратно скажу, что я такого не видел. Можно и правда идти от дедлайна по фиче, автоматически смотреть какие дедлайны и связи задач... но пока звучит как фантастика.
Я решаю это просто - есть РП или продакт, которы определяет, что пускаем в работу и все.
Да, если капасити команды меньше, чем объем задач, может получиться, что какие то задачи начнут "краснеть" и пойдут в работу с повышенным приоритетом. Ничего криминального не вижу - нормальная логика стека, когда входящий объем больше обрабатываемого.
Главное, следить надо за тем, чтобы общий входящий объем не превышал капасити команды продолжительное время - тогда начнутся задержки. Это уже не решить приоритетами, это решается планированием ресурсов команды.
хы, а я думаю, че у меня дежавю чтоли? Я читал аналогичный пост много лет тому от самой Мосигры )) спасибо каментам, внесли ясность, что история пошла на повтор)
Не раскрыта тема визализации зависимостей задач между собой, или ваши проекты настолько простые, что их просто нет? Но ведь фронт от бекенда зависит, к примеру, тогда как отслеживаются зависимости? депендансями в тикетах? А как это визализировать (то есть Гантт где?)
В целом, если у вас простой комбайн, который фигачит поток входящих небольших (до 2х мес) CRы, они же ЗНИ, то да. Как только вы начинаете работать с проектными зависимостями, канбан не панацея.
Откуда уверенность: да чисто мои ощущения. Никаких расчетов у меня нет.
Есть, конечно, базовые правила работы с удаленкой:
контроль показателей разработки, никаких задач без трекера, процесс разработки/тестирования и прочее
джунов надо набирать только под толковых и проактивных лидов, которые сами будут джунов пинать и контролировать.
костяк точно должен быть сильный (впрочем как и в офлайн компании).
ну и наверное надо почаще общаться с лидами и сотрудниками и не лениться делать голосовые или даже видео встречи. Чтобы никто не чувствовал себя брошенным
А с ругой стороны тратить на брейнсторминг больше часа в день = сжигать ресурсы на ППР встречи.
А с другой стороны, в офисе галдеж, вышли покурить и то-се. Я и сам гораздо лучше пишу доки, к примеру, дома. В офисе лучше коммуникация - это факт. И своим опытом необходимо и достаточной коммуникации я поделился.
А про контроль времени я вас не понял :) чего это контора сразу идет нахер, зачем? )
я не знаю, что такое тредофф, никогда не пользовался термином. Если поясните попроще - отвечу )
НИОКРы тоже разные бывают, есть чистые научные исследования - никогда не работал, но если было бы надо - просто планировал работу и примерные цели в формате "было бы неплохо" и тестировании гипотез, пока бабло есть
НИОКР как создание нового продукта - ну тут все +- структурировано: MVP, backlog с приоритизацией и гипотезы.
ТАк что если есть четкая постановка и вопрос - говорите, иначе слишком общий разговор получится
Вообще, сбор статистики по метрикам среднего выполнения, отклонений и тп - безусловно интересная штука.
При этом отказ от оценок разработчиками ведет нас к паре интересных моментов
Разработчик не несет ответственности за сроки. С одной стороны, мы создаем комфортную среду для разработчика, с другой - снимаем с него ответственность за выполнение задачи. А ответственность - мера взрослости. Умение дать оценку и попасть в нее - это , по сути, менеджерский скилл. А менеджер, по Адзизесу - любой, кто дает срок на работу. То есть оценка задачи и последующее старание попасть в эту оценку создает стресс для работника, но в тоже время каждый раз делает его профессиональнее. Разговоры про искусственные завышения оценок валидны только если доверия в команде нет. Там ребята начинают страховаться. Но это претензия к РП, это не проблема исполнителей.
Итого:
- оценка в часах помогает расти команде профессионально, обучаясь ответственности
- оценка в часах позволяет выделить узкие места процесса (сотрудник) и , поговорив с ним, добавить в это место резервирование.
Может возникнуть соблазн (раз уж мы заботимся об исполнителях) вообще не учитывать время в трекере, потраченное на задачу. А вот тут последствия вообще могут быть печальными (некорректный учета факта)
если вам не надо обещать сроки - замечательно можно работать.
как сказала одна девочка РП из Яндекса на каком то тренинге: "вы знаете, наш best practice, это по возможности не давать никаких сроков заказчику, потому что все может поменяться.
А заказчики, паразиты, вечно просят определенности, все беды от них :)
Если серьезно, когда РП подписывается под срок реализации, он должен подписываться не сам (ибо он просто админ), а с командой. Вот тут каждый участник начинает отвечать за свою работу. И тут у каждого исполнителя персональная отвествтенность
Спасибо. Да, статья несерьезная. А, впрочем, вполне серьезная, потому что позволяет применить опыт компромиссов, формирования ожиданий и на работе и в личных отношениях. Да и вывод тут важный: отношения заканчиваются, это вообще нормально. Важно сделать выводы и так, как косячил, больше не делать. И в следующий раз будет лучше. А если выводы не сделать, будет также. Я считаю, для работы это важно - рефлексия и исправление ошибок - часть профессионального роста.
А минусят за неправильные хабы, похоже, но я искренне не понимаю, чего неправильного, хабы именно те, что надо :)
Ага, спасибо за ответов, сам придерживаюсь тогоже: инструмент не важен, процесс первичен.
по замерам параметров тоже спасибо, понял!
спасибо. в целом не вижу сильных отличий от стандартной разработки:
вы делаете план работ в Мерлине (а ктото в проджекте). Чем ваш подход лучше общего на рынке?
вы делаете декомпоз работ и осаживаете его на трекер (задачи). Вы делаете в своей системе (как я понял), а большинство - в JIRA (и JIRA гибче вашей системы). Чем ваш подход лучше?
Все остальное - детали и метрики, специфичные для кажой компании.
И кстати, вопрос 3 - вы помянули, что сократили time-to-market. А как считали сокращение, расскАжите?
тру
Да, у меня точно такой же опыт.
с 5 по 11 класс в школе
с 1 по 3 курс в институте
2 года англ курсов отдельно
Приехал в Аус по работе - и я понял, что сказать ничего не могу. Только практика, только хардкор. А правило зеленой ручки относится не только к английскому - оно вообще про перфекционизм (да чтоп ему повылазило).
ну я поставил например.
как человек, который учил английский в школе с 5го класса (твердое 4)
как человек который учил в институте (4 и зачет)
как человек который учился на курсах (5, разумеется)
а потом приехал по работе в Австралию и не понял нихрена и связать 2х слов не смог. А через полгода спикал только в путь даже с небольшим вокабуляром. Просто перестал париться про акцент и это наше вечное "как сказать правильно".
Статья в точку. А то что автор рекламирует в конце - и чего такого? Контент годный, опыт у чувака есть.
тут можно делать по-разному. Если приоритет везде равный, это, по умолчанию, означает, что порядок - на усмотрение производства. Если есть менеджер, то на его усмотрение (обычно он все таки есть).
Если менеджера нет и есть желание сделать полностью автоматический конвеер... ну я аккуратно скажу, что я такого не видел. Можно и правда идти от дедлайна по фиче, автоматически смотреть какие дедлайны и связи задач... но пока звучит как фантастика.
Я решаю это просто - есть РП или продакт, которы определяет, что пускаем в работу и все.
Да, если капасити команды меньше, чем объем задач, может получиться, что какие то задачи начнут "краснеть" и пойдут в работу с повышенным приоритетом. Ничего криминального не вижу - нормальная логика стека, когда входящий объем больше обрабатываемого.
Главное, следить надо за тем, чтобы общий входящий объем не превышал капасити команды продолжительное время - тогда начнутся задержки. Это уже не решить приоритетами, это решается планированием ресурсов команды.
хы, а я думаю, че у меня дежавю чтоли? Я читал аналогичный пост много лет тому от самой Мосигры )) спасибо каментам, внесли ясность, что история пошла на повтор)
прикольно, а посты тогда были такие романтичные )
Не раскрыта тема визализации зависимостей задач между собой, или ваши проекты настолько простые, что их просто нет? Но ведь фронт от бекенда зависит, к примеру, тогда как отслеживаются зависимости? депендансями в тикетах? А как это визализировать (то есть Гантт где?)
В целом, если у вас простой комбайн, который фигачит поток входящих небольших (до 2х мес) CRы, они же ЗНИ, то да. Как только вы начинаете работать с проектными зависимостями, канбан не панацея.
вы не поверите. в экселе, проджекте и джира.
нет инструмента, о котором вы писали по прежнему
прочитал.
Откуда уверенность: да чисто мои ощущения. Никаких расчетов у меня нет.
Есть, конечно, базовые правила работы с удаленкой:
контроль показателей разработки, никаких задач без трекера, процесс разработки/тестирования и прочее
джунов надо набирать только под толковых и проактивных лидов, которые сами будут джунов пинать и контролировать.
костяк точно должен быть сильный (впрочем как и в офлайн компании).
ну и наверное надо почаще общаться с лидами и сотрудниками и не лениться делать голосовые или даже видео встречи. Чтобы никто не чувствовал себя брошенным
чтобы я, как менеджер, понимал, когда разработка закончится и мог планы планировать.
А еще следил за прогрессом выполнения по декомпозированным задачам.
А товарищ разработчик старался уложиться в данные им сроки.
И да, я в курсе про "раз вы будете просить оценивать, мы будем давать завышенные оценки" и знаю, что на это отвечать :)
А с ругой стороны тратить на брейнсторминг больше часа в день = сжигать ресурсы на ППР встречи.
А с другой стороны, в офисе галдеж, вышли покурить и то-се. Я и сам гораздо лучше пишу доки, к примеру, дома. В офисе лучше коммуникация - это факт. И своим опытом необходимо и достаточной коммуникации я поделился.
А про контроль времени я вас не понял :) чего это контора сразу идет нахер, зачем? )
я не знаю, что такое тредофф, никогда не пользовался термином. Если поясните попроще - отвечу )
НИОКРы тоже разные бывают, есть чистые научные исследования - никогда не работал, но если было бы надо - просто планировал работу и примерные цели в формате "было бы неплохо" и тестировании гипотез, пока бабло есть
НИОКР как создание нового продукта - ну тут все +- структурировано: MVP, backlog с приоритизацией и гипотезы.
ТАк что если есть четкая постановка и вопрос - говорите, иначе слишком общий разговор получится
на тему как писать правильно: "комменты" или "каменты" я еще не спорил :)
у меня это из 2000х, когда был сайт Лурк и там был сленг в стиле "КГ/АМ", "насрал в каментах" и тд :)
и да, вы не душнила, вы - настоящий аналитик, вы именно такие и должны быть в моем понимании :)
а что такое в вашей системе координат будет тогда "кретин" ?
Вот вас минусанули, а молитву Оптинских старцев я отлично знаю, внезапно :)
угу. на войну поедете? по сравнению с ней и ваша вахта - фигня. А налаживать связь из окопа - вполне себе айтишка тоже.
к чему я это: обесценить можно вообще все, что угодно, это обыкновенный манипулятивный прием.
С тем, что статья не впечатлила - да ок, конечно. Это просто личный опыт, он может отзываться или нет, это нормально.