Круто, что есть разные версии — мы будем делать полушуточную PHP-викторину в перерыве, спросим людей, что они считают более лучшим. Спасибо, что благодаря вам родилась идея!
Привет! А мы как раз один из следующих митапов планируем с Кириллом Смеловым, разработчик из команды PhpStorm в JetBrains: он готов приехать в Мск. Так что, думаю, в декабре-январе можно будет лично фидбек дать)
Привет, пессимистичненько( Были тут на выходных в Нижнем на митапе, многие опасаются того же — в том числе потому, что в вузах мало программ от компаний.
Хорошо, что у нас разработчиками не директор руководит) Но если серьезно у нас разные взгляды, я понял. Спасибо, что высказались и дали возможность высказаться в ответ.
> А почему мне должно быть не плевать на прибыль компании?
Приведу примеры, которые сам знаю из рассказов наших ребят (спойлер: конечно, речь пойдет не про прибыль компании — это больше волнует акционеров, а про то, что зовут юнит-экономикой — т.е. в целом понимание, что у нас есть ресурсы и некий ожидаемый профит, и то или иное действие или бездействие можно примерно пересчитать на деньги)
Например:
1. Наши ребята много лет остаются на стеке Angular/PHP, тк это экономически более оправдано, чем переписать все с нуля. Но выбили себе время на рефакторинг в спринте — тк донесли бизнесу его языком, что это значит в плане той самой «прибыли». Регулярно обновляются на свежие версии, но не всегда используют какие-то фишечки, если не могут объяснить себе и бизнесу, что это даст продукту — в ангуляр-подкасте было несколько примеров у Виталика.
2. Наши дизайнеры сделали в эксельке калькулятор «сколько стоит запилить фичу для проверки гипотезы» — чтобы как раз все ребята из дизайна поняли, как в плане ресурсов в жизни строится процесс.
В целом, в продуктовых компаниях, кажется, приветствуется именно такой подход — когда тимлид и разработчик учитывает бизнес-критерии при решении задач. Но это лишь один из возможных подходов — и нормально, если вы считаете иначе.
Привет! Еще из свежего-полезного появилось видео с первого нижегородского PHP-митапа, который прошел 2 ноября. В программе было 4 доклада: про опыт наставничества, хранения фото, работу с событиями и очередями. У видео доступна разметка — можно сразу мотать на интересный доклад.
Думаю, это даже не проблема KPI, а всего человечества: все хорошее хочется распространить, но при масштабировании оно теряет индивидуальность. Одежда, транспорт, еда, да, кажется, все. Но живем в век персонализации, так что, может, и это вылечат еще при нас)
Думаю, тут как со всем — тестируем и находим работающее для себя. У нас недавно тимлид одной из команд делал доклад (вот ютуб-версия), как они учились оценивать задачи с ребятами, чтоб и заказчик внутренний понимал и принимал, и самим нормально жилось. Сломали много копий, отбросили ряд моделей, где-то по ходу что-то напильником подпиливали — но смогли найти рабочую схему.
При этом не факт, что она у других так же ляжет: но, кажется, рецепта кроме «бороться и искать, найти и не сдаваться» еще не придумано(
Ну в моей работе (я devrel, не разработчик) они есть — из хорошего, я их сам выбираю, по сути: просто созваниваемся с руководителем, обсуждаем, что хотим/нужно сделать в ближайшие месяцы + как мы будем измерять. KPI — это же индикатор, те измерение)
У разработчиков от команды к команде может быть по-разному (тут команды продуктовые обычно сами договариваются внутри, как жить, а разработчики по продуктовым командам именно сидят), но квартальное планирование есть, это факт.
p.s. На всех трех моих работах, где было что-то про ИТ именно, у разработчиков и не только была система бонусов за результат в течение нескольких месяцев/крупного проекта/еще чего. Кажется, это частая практика на неделе, но могу быть нерепрезентативен
Привет, работаю тут, с бонусами проблем не было пока — это не золотые горы, а просто приятная прибавка: расчитывается на основании KPI квартальных, по крайней мере, у меня
Привет, спасибо за интересный вопрос! Мы в Skyeng ввели обучение работе со слаком для всех при онбординге — это часть вводного курса (инструкция в картинках и правила общения) с проверочными заданиями. Плюс ребята многие не стесняются подсказывать («пиши все мысли в одном сообщении»), напоминать о договоренностях (что SLA на ответ в слаке 3 часа в рабочее время, например, или что рабочее в рабочем мессенджере, а телеграм — это если срочно или внешние контакты) — т.е. дообучают в процессе немного, если что.
Я тоже не разработчик, но быстро привык, например — наоборот, теперь функционала напоминалок из слака дико не хватает в том же телеграме. И вижу, что тут много девушек в дизайне, например, в менеджменте — не замечал у них проблем. Так что вводный курс-инструкция с легким напоминанием правил в процессе коммуникации работают, кажется.
Хорошо, что у нас разработчиками не директор руководит) Но если серьезно у нас разные взгляды, я понял. Спасибо, что высказались и дали возможность высказаться в ответ.
> А почему мне должно быть не плевать на прибыль компании?
Приведу примеры, которые сам знаю из рассказов наших ребят (спойлер: конечно, речь пойдет не про прибыль компании — это больше волнует акционеров, а про то, что зовут юнит-экономикой — т.е. в целом понимание, что у нас есть ресурсы и некий ожидаемый профит, и то или иное действие или бездействие можно примерно пересчитать на деньги)
Например:
1. Наши ребята много лет остаются на стеке Angular/PHP, тк это экономически более оправдано, чем переписать все с нуля. Но выбили себе время на рефакторинг в спринте — тк донесли бизнесу его языком, что это значит в плане той самой «прибыли». Регулярно обновляются на свежие версии, но не всегда используют какие-то фишечки, если не могут объяснить себе и бизнесу, что это даст продукту — в ангуляр-подкасте было несколько примеров у Виталика.
2. Наши дизайнеры сделали в эксельке калькулятор «сколько стоит запилить фичу для проверки гипотезы» — чтобы как раз все ребята из дизайна поняли, как в плане ресурсов в жизни строится процесс.
В целом, в продуктовых компаниях, кажется, приветствуется именно такой подход — когда тимлид и разработчик учитывает бизнес-критерии при решении задач. Но это лишь один из возможных подходов — и нормально, если вы считаете иначе.
При этом не факт, что она у других так же ляжет: но, кажется, рецепта кроме «бороться и искать, найти и не сдаваться» еще не придумано(
У разработчиков от команды к команде может быть по-разному (тут команды продуктовые обычно сами договариваются внутри, как жить, а разработчики по продуктовым командам именно сидят), но квартальное планирование есть, это факт.
p.s. На всех трех моих работах, где было что-то про ИТ именно, у разработчиков и не только была система бонусов за результат в течение нескольких месяцев/крупного проекта/еще чего. Кажется, это частая практика на неделе, но могу быть нерепрезентативен
Я тоже не разработчик, но быстро привык, например — наоборот, теперь функционала напоминалок из слака дико не хватает в том же телеграме. И вижу, что тут много девушек в дизайне, например, в менеджменте — не замечал у них проблем. Так что вводный курс-инструкция с легким напоминанием правил в процессе коммуникации работают, кажется.