А как на ваш взгляд должна быть построена организация процесса? Исходя из финансовой направленности вашей деятельности - было бы интересно выслушать ваш взгляд на эту проблему.
Хотя, мне кажется, что это общий тренд. Как пример, "True Tech Champ" от МТС. Тоже оформлен в мягких тонах, несмотря на то, что там именно чистый хакатон.
А вот то, что в cybercamp был мультик, который проходит нитью через все три дня - это действительно оригинально. Ранее мне такое не встречалось.
Описывать его не стал - его лучше просто посмотреть :)
Компания (вероятно) обладает очень хорошим планированием (в условиях нетипичных задач).
Верно
20% времени в планировании заложено на свободное творчество.(Вероятно) эти же 20% являются буфером компенсации накладок и ошибок планирования.
Верно, хотя именно как буфер этот запас используется крайне редко
Свободное творчество помогает:
разработчику воплощать собственные задумки и продавать, обменивать или реализовать личные проекты с помощью компании;
компании генерировать полезные идеи и наработки благодаря потенциалу "корпоративного инкубатора" (плюсом является знакомство разработчиков с устройством и процессами компании).
Не верно. Основная задача этого временного отрезка - повышать навыки сотрудника. Будем объективны, 99,9% всех идей и задумок никогда никем не будут воплощены по множеству разных причин. Соответвенно получение идей / MVP - не самоцель.
WL-blend реализуется только в части собственного профессионального творческого потенциала в рабочее время. В остальном WL-blend нереализуем, т.к непрофессиональные дела находятся за регламентом рабочего времени (те же условные с 9:00 до 18:00).
Юридически - да. Компания не может претендовать на нерабочее время и это правильно. Но опять же, учет осуществляется не на базе времени ("спички не считаем"), а на базе задач. Вероятно, что у вас пока не складывается разница между этими понятиями.
И еще вопрос, если не секрет: каков масштаб команды разработчиков и менеджеров, чтобы компании такой подход шел на пользу?
Из практики - любой. Контроль осуществляется на базе линейных руководителей и, если выдержано корректное соотношение 1 руководитель к 7 сотрудникам, то такой подход легко масштабируется. Если компания придерживается формата 1 управленец на 100 разработчиков, то этот формат применить не выйдет - все начнут просто отдыхать.
Здесь стоит отметить и то, что WLB накладывает серьезные ограничения на качество управляющего состава и сотрудников. Как пример, не все могут работать в состоянии ослабленного контроля, некоторым всегда требуется пристальное внимание руководителя.
Т.е. не исключаю, что для ряда сотрудников такой подход вообще будет неприменим и придется делать выбор между "расстаться с сотрудником" или "контролировать по-старому".
Если вы имеете ввиду подход, то да - он крайне редко встречается. Собственно статья как раз и попытался раскрыть, что на рынке доминирует "обратный" тренд, хотя его эффективность довольна спорная, как мне кажется.
Если компания действительно может выделять время для личных проектов, то это было бы мощным преимуществом, о котором следует заявлять громко, ясно и прямо
Согласен частично. В данном случае мы просто говорим "как есть", скрывать нет смысла - это не тайна. Пиарить тоже - штат уже полностью укомплектован :)
...высок соблазн покрывать ошибки планирования и накладки тем самым свободным временем...
Если это такие ошибки, то сотрудники начинают скучать и увольняются. Знаю много примеров, когда мотивом перехода становилась именно "скука". У нас за время существования компании 0 увольнений среди разработчиков :)
В планируемом 1-месячном проекте уже заложено 20% для себя.
Это верное утверждение. Только не нужно воспринимать "для себя" как "пойду поиграю в футбол". "Для себя" - это обучение за счет компании, а не отпуск :)
А если скажем работа успешно сделана за 50% времени (2 недели), то как будет планироваться запас времени на следующий такой же типовой проект?
Как встретим второй "типовой проект" - обязательно расскажем. Из практики - ни одна задача ни разу не повторилась. А то что повторяемо, например разворачивание сервера, уже давно заскриптовано :)
...а значит руководство не увидит сколько времени высвобождает сотрудник...
Попробую объяснить, есть срок сдачи продукта. Предположим, что вам нужно реализовать 1 модуль за 5 рабочих дней. В данном случае измеримый KPI - это 1 модуль. Мы стараемся абстрагироваться от часов, но если вам так удобнее мыслить, то пусть под это есть 40 рабочих часов.
Разложим задачу по SMART: S - конкретная задача, модуль имеет четкое описание M - измеримость, 1 модуль A - достижимый, прежде чем ставить задачу ее детали проговариваются. Собственно здесь бизнес-аналитик работает и его задача сделать задачу достижимой. R - значимый, тут понятно, цель важна для бизнеса T - ограничение во времени, есть лишь 5 дней.
Сотрудник сдал его за 4 рабочих дня, т.е. затратил 32 часа. 40 - 32 = 8 часов разницы. Все вполне измеримо и прозрачно.
...и будет волен распорядится им хоть для свободной охоты или хоть для отдыха на свое усмотрение ...
Для свободной охоты - да. Для отдыха - только если руководитель понимает, что через те самые 8 часов будет проект высокой сложности. Такое редко, но бывает.
Хотя опять же, пока никто не жаловался, что обучение не дает отдохнуть. Мозг переключается, дедлайна нет, можно пить кофе или слушать лекцию на прогулке в парке. Обучение - это не всегда написание кода.
Если тут на самом деле отсутствует кажущееся противоречие, то хорошо.
Попробую перефразировать. Компания готова выкупать права на хорошие pet-проекты сотрудников. Возможно так стало понятнее :)
Частично с вами соглашусь. Действительно, джунов с ожиданиями по ЗП как у мидлов - прорва. Ожидания "входа в ИТ" начинаются от 150к, даже если это интерн полный, которого еще учить и учить. Но не всегда дело в этом.
Еще бывает: 1) Нецелевой стэк технологий. Если вы умете в Java, а нужен С++, то вы не нужны. Если в компании используется фрейм 1, а вы знаете фрейм 2, то вас не возьмут. Никто не хочет вкладываться в обучение сотрудника, потому что есть страх "обучится и уйдет". 2) HR со странностями. Данный персонаж оценивает соискателя не по навыкам, а по тому, нравитесь вы ему или нет. Половину вопросов такой HR не понимает, другую половину перефразирует во что-то типа "HTML знаете? Вот вам листочек - напишите страницу" или "Java знаете? Значит JavaScript вам близок" :) 3) Руководитель с детской травмой. Тоже встречается на просторах вселенной случай, когда руководитель боится брать более скилловых подчиненных. На мой взгляд должно быть наоборот, ведь руководитель по определению "широкий спец", который "в глубину" не умеет, у него задачи другие. Вот и получается, что он набирает "слабеньких", чтоб на их фоне быть "умным". В этом случае, чем выше ваш уровень - тем ниже шанс быть принятым на работу.
Значит сотрудник теперь может делать 2 продукта в месяц - тогда понятна выгода бизнесу. Но какая от этого выгода сотруднику?
Как я писал выше, у сотрудника появляется период, когда новая задача еще не пришла и в этот период у него то, что у нас называется "свободная охота". Сотрудник изучает то, что ему интересно и имеет потенциальную пользу где-то позже в проектах. Иногда, проект сразу не приходит и состояние "охоты" может длиться порядка недели.
И как все это выглядит в плане интенсивности труда: сотруднику выгодно интенсивность труда в среднем понижать, врать в эстимейтах и логировании, и делать продукт все тот же месяц, а бизнесу наоборот - интенсивность повышать (2 продукта/мес) - отчего в т.ч. и происходит выгорание.
С какой целью занижать интенсивность, если после окончания проекта никто ничего "не накидывает"? Как раз интенсивность идет в рост, так как сотрудник понимает, что может обеспечить себе легальную "свободную охоту", а это сразу означает отсутствие дедлайнов и пушей в git.
Бизнесу выгодно "заканчивать проекты", чем их будет больше завершено - тем выше прибыль. И снижать стоимость поддержки тоже выгодно, а это достигается качеством кода. Т.е. давая обучаться мы снижаем расходы, как я и писал выше.
Похоже, что свои интересы позволены сотруднику до поры до времени пока отдел продаж не обеспечит команду 2 заказами в месяц, и тогда никакого свободного времени не останется. Сотрудники рано или поздно это поймут, и начнут внедрять "свободное время" скрытно от руководства, опять замедляя свою работу и провоцируя недоверие и токсичность.
И да, и нет. Мы изначально планируем времязатраты так, чтоб у сотрудника было примерно 20% времени на изучение дополнительных материалов. Загнать сотрудника в рутину "делай-делай" - это прямой путь к выгоранию и увольнению. Т.е. если заказов приходит больше, чем способна вытянуть команда, то это повод задуматься о "горизонтальном расширении" как раз, у нас такое уже случалось. "Выжигать людей" - порочная практика хотя бы потому, что следом вы получите "-1" качественный сотрудник и "+1" человек в обучение, что явно выйдет дороже.
И заметьте, время выигранное от повышения квалификации сотрудника не достается ему для восполнения того самого лайф-баланса - так как же ему от этого не выгорать?(Не понял про "вовлечение в процессы")
Как раз далее в статье написано, что в мире IT вариант LB сложно реализуем и требуется переход к WLB. Сам концепт WLB не дает выгорания, потому что работа становится не рутиной с 9 до 18, а процессом внутри жизни. Работа становится высокооплачиваемым хобби, если так удобнее воспринимать. Тут сразу оговорюсь, что если сотрудник попал "по ошибке" в IT, то для него такой режим станет каторгой :)
Тут интересно подробней. Компания претендует на права на такие проекты, потому что они выполнялись в рабочее время? Или сотрудник имеет право выторговать себе преференции и наконец завоевать свой ворк-лайф-баланс выходом из роли наемного работника?
Юридические детали раскрывать не буду, но суть сводится к тому, что хорошие задумки становятся собственностью компании юридически, на них передаются полные права.
Торговаться у нас не принято - это потеря времени. Нужно что-то, сотрудник озвучивает и далее пытаемся решить вопрос. Если он решаемый - соглашаемся. Если нет - предлагаем варианты и думаем далее. В частности, так решается вопрос платного доступа к тематическим ресурсам, например.
Выгода разработчика - проект может получить инвестирование в разработку и улучшение, если докажет жизнеспособность. Однако, если разработчик хочет, может разрабатывать самостоятельно без передачи прав - никто мешать не будет.
Важно понимать, что большинство проектов "в одиночку" не делаются, а если и делаются, то заканчиваются в git open sourse без финансовой выгоды для разработчика.
Слишком много человеко-часов требуется, чтоб создать хотя бы MVP. А следом идет внедрение, переговоры с потенциальными заказчиками и т.п. Следом требуется UI/UX перенастройки под фокус группы, CI/CD и расчет мощностей и прочее. Ни один человек не в силах изучить все, к сожалению.
Т.е. сотрудник превращается из разработчика в гендира с командой узких спецов и забывает про код. Про LB и WLB можно забыть, это фактически запуск бизнеса с нуля. Ну и про конфликт интересов не нужно забывать. Мы же нанимаем разработчика, а не стартапера со своей независимой командой :)
Из нашей практики мало кто хочет менять профиль ради идеи, которая не факт, что "выстрелит". А компания как раз берет на себя этот риск, ей выгодно, чтоб идея сработала. При этом разработчик рад тому, что идея жизнеспособна и над ней можно работать далее, развивая ее в рабочее время.
Если расскажете чуть подробнее о вашем стеке и фреймворке - возможно, что смогу дать рекомендации. Но самое вероятное - ваш стек "узкий" и как итог компаний, которые готовы вас принять, будет не очень много и в них высокий порог входа.
Как пример, для ООО "Ромашка" у вас не хватает навыков из смежных областей (там часто хотят кросс-возможности, например фулл-стек, бек + DevOps и т.п.), а для IBM у вас не хватает уровня - им нужны узкопрофильные Боги Разработки.
Вот и получается "мертвая долина", где, вроде бы навыки у вас есть, но ощущение, что они никому не нужны.
Если мы говорим о внешнем заказчике, то по сути он заказывает не часы работы, а "услугу по разработке", иначе это уже аутсорс получается.
В этом случае окончание работ "до срока" - это прямая выгода РМ компании разработчика, так как сотрудники потенциально могут заняться другими проектами, т.е. приносить прибыль. Справедливости ради, обычно возникает пауза хотя бы дня в 3 между ними, т.е. "есть время обучению". Даже если разработчики 2 недели будут просто заниматься обучением - это уменьшит срок старта и затраты на эксплуатацию новых проектов, т.е. будет наблюдаться эффект отложенной прибыли.
А еще это дает хорошие гарантии того, что "проект успешно сдан", поскольку остается время на дебаг, если он возникнет. Т.е. PM закрывает свой KPI с гарантией и это ему выгодно. Ну и никакого выгорания, все понимают, что укладываются в сроки.
Если заказчик получает продукт раньше срока, то он может начать ускорять остальные процессы. В моей практике все заказчики коммерческого сектора приходят с запросами "нужно было вчера, чем быстрее - тем лучше". Отсюда и вывод, что им это тоже выгодно.
Если под "идея дать денег разработчику" подразумевается премия, то она тоже выписывается, но реже. Мы предпочитаем индексирование ЗП - это эффективнее и понятнее. По крайней мере у нас всех устраивает такой подход :)
Спасибо за вопрос. Исхожу из того, как это работает у нас в компании и этот подход финансово обоснован, кстати.
Действительно, бизнес - это извлечение прибыли. Однако, если владелец заточен строго на прибыль, а не на расширение бизнеса, то с высокой долей вероятности такой бизнес схлопнется со временем. Владелец просто "обескровит" бизнес, забрав прибыль.
Если говорить о разработке, то инвестиция в бизнес там может быть лишь в ширину или в глубину. Я сейчас не о продажах, а именно о разработке и разработчиках. Ширина - это "раздуть" штат. Глубина - это улучшить навыки тех, кто уже есть, чтоб работы производились лучше и быстрее.
Опыт стартапов показывает, что "ширина" быстро выедает бюджет. И создает "токсичность", ведь все примерно равны в навыках и пытаются доказать друг-другу, кто круче. Следом начинают требоваться тимлиды, которые тоже требуют ЗП и т.п. Т.е. расходная часть растет очень быстро. В отличии от "глубины".
Она позволяет делать продукт качественнее, снижая его стартовые и эксплуатационные расходы. Там где сотрудник делал 1 продукт за месяц он начинает собирать тот же продукт за 2 недели. При этом нет "притирочных" периодов, потому что не меняется штат. Далее, когда придет новый сотрудник, его не будут "токсить", а помогут быстро адаптироваться сами разработчики, потому что новый сотрудник никакой угрозы им не представляет с точки зрения навыков.
Таким образом, если новые проекты приходят, то сотрудники спокойно работают без горящих дедлайнов. Соответственно и выгорать перестают. А свободное время легально уходит на "свои интересы", что снижает уровень недоверия. Или "на личные проекты", что тоже весьма интересно, ведь в это случае они являются архитекторами этого проекта, который далее можно будет развивать совместно с бизнесом. Здесь нужно понимать, что удачные проекты бизнес в любом случае будет пытаться развить и "одиночки разработчики" нормальный проект не создадут, только в команде. Это длительный процесс.
По PR - согласен. Однако, лично у меня были ожидания новых продуктов, которые не оправдались. Отсюда и статья о "странных" трендах.
Спасибо за комментарий. Ваша мысль передана грубо, но мне понятна. Однако, если вы пообщаетесь с HR, то поймете, что они действительно верят в то, что делают.
Я бы назвал это некоторым заблуждением с их стороны, когда вера в то, что "игра работает" доминирует над реальностью. А раз никто не дает отрицательных отзывов (запрещено, на это же средства были выделены) - значит все работает отлично.
Касательно подмены понятий "специалист" и "обслуга" - не соглашусь. Не так давно мы искали разработчика. Удалось найти нужный уровень кандидате лишь на 30-ом человеке. Очень много тех, кто 3 дня учил язык на вебинарах и теперь хочет 300 000 в месяц.
Основная мысль тезисов в том, что понятные и прозрачные критерии, нам мой взгляд, пытаются заменить на непонятную виртуальную вселенную. И, видимо, это уже намеченный тренд. Из моей практики такой подход не работает.
Заработная плата "в рынке" - это гигиенический фактор, он просто должен быть. Если работодатель платит ниже рынка, то он должен быть готов к оттоку высококлассных кадров. Удерживать сотрудника "вечно" даже при идеальных условиях сложно, а при низкой ЗП - это просто "карусель кадров".
Однако и давать "плюшки" без достижений - тоже не стоит. Это порождает кадровую инфляцию. Те самые 5 офферов за год :)
И как итог появляется тот самый "рынок соискателя", который плох и для соискателя, тоже. а) Вместо развития компании начинают вкидывать деньги в заработные платы, б) которые провоцируют реальную инфляцию, в) которая обесценивает высокую заработную плату, г) как итог услуги компании становятся менее востребованы, д) что ведет к сокращению штата, е) что может привести к увольнению
По удаленке, да, наверное стоит давать выбор. Согласен с утверждением
Как раз такая система использовалась "в базе", происходил подлог меток или передача сменщику, чтоб пробил. Как итог на объекте 1 человек, а ЗП получат два.
При этом проверять "онлайн" всех по камерам заказчик не может в силу финансовых затрат. Объектов очень много
На самом деле уже планируется к выпуску вторая часть, которая будет опираться строго на документацию самого ЦБ, как первоисточника инновации.
Можно назвать эту часть "Цифровой рубль по версии СМИ и техно-блогов", посмотрим сойдется ли описание с описанием самого ЦБ во второй части "Цифровой рубль глазами разработчика". Уже, на этапе сбора материалов, вижу, что есть некоторые интересные расхождения. Плюс добавится сводная таблица для удобства чтения данных.
А как оно будет реально запущено - узнаем в середине 2025 года :)
Спасибо за комментарий.
А как на ваш взгляд должна быть построена организация процесса?
Исходя из финансовой направленности вашей деятельности - было бы интересно выслушать ваш взгляд на эту проблему.
Да, действительно, оформление очень "мягкое".
Хотя, мне кажется, что это общий тренд.
Как пример, "True Tech Champ" от МТС.
Тоже оформлен в мягких тонах, несмотря на то, что там именно чистый хакатон.
А вот то, что в cybercamp был мультик, который проходит нитью через все три дня - это действительно оригинально.
Ранее мне такое не встречалось.
Описывать его не стал - его лучше просто посмотреть :)
Вам тоже спасибо!
Действительно вышло конструктивно :)
Мысль развернуть в отдельной статье тему интересная,
подумаю, получится ли ее расписать так, чтоб было понятно как это "сходу" применить.
Правда впереди еще вторая часть "цифрового рубля" и "хакатон" ;)
Если не секрет, то вы в какой области работаете (направление деятельности компании) и почему возник такой интерес к этой тематике?
Верно
Верно, хотя именно как буфер этот запас используется крайне редко
Не верно.
Основная задача этого временного отрезка - повышать навыки сотрудника.
Будем объективны, 99,9% всех идей и задумок никогда никем не будут воплощены по множеству разных причин.
Соответвенно получение идей / MVP - не самоцель.
Юридически - да.
Компания не может претендовать на нерабочее время и это правильно.
Но опять же, учет осуществляется не на базе времени ("спички не считаем"), а на базе задач.
Вероятно, что у вас пока не складывается разница между этими понятиями.
Из практики - любой.
Контроль осуществляется на базе линейных руководителей и, если выдержано корректное соотношение 1 руководитель к 7 сотрудникам, то такой подход легко масштабируется.
Если компания придерживается формата 1 управленец на 100 разработчиков, то этот формат применить не выйдет - все начнут просто отдыхать.
Здесь стоит отметить и то, что WLB накладывает серьезные ограничения на качество управляющего состава и сотрудников.
Как пример, не все могут работать в состоянии ослабленного контроля, некоторым всегда требуется пристальное внимание руководителя.
Т.е. не исключаю, что для ряда сотрудников такой подход вообще будет неприменим и придется делать выбор между "расстаться с сотрудником" или "контролировать по-старому".
Если вы имеете ввиду подход, то да - он крайне редко встречается.
Собственно статья как раз и попытался раскрыть, что на рынке доминирует "обратный" тренд, хотя его эффективность довольна спорная, как мне кажется.
Согласен частично.
В данном случае мы просто говорим "как есть",
скрывать нет смысла - это не тайна.
Пиарить тоже - штат уже полностью укомплектован :)
Если это такие ошибки, то сотрудники начинают скучать и увольняются.
Знаю много примеров, когда мотивом перехода становилась именно "скука".
У нас за время существования компании 0 увольнений среди разработчиков :)
Это верное утверждение.
Только не нужно воспринимать "для себя" как "пойду поиграю в футбол".
"Для себя" - это обучение за счет компании, а не отпуск :)
Как встретим второй "типовой проект" - обязательно расскажем.
Из практики - ни одна задача ни разу не повторилась.
А то что повторяемо, например разворачивание сервера, уже давно заскриптовано :)
Попробую объяснить, есть срок сдачи продукта.
Предположим, что вам нужно реализовать 1 модуль за 5 рабочих дней.
В данном случае измеримый KPI - это 1 модуль.
Мы стараемся абстрагироваться от часов,
но если вам так удобнее мыслить, то пусть под это есть 40 рабочих часов.
Разложим задачу по SMART:
S - конкретная задача, модуль имеет четкое описание
M - измеримость, 1 модуль
A - достижимый, прежде чем ставить задачу ее детали проговариваются.
Собственно здесь бизнес-аналитик работает и его задача сделать задачу достижимой.
R - значимый, тут понятно, цель важна для бизнеса
T - ограничение во времени, есть лишь 5 дней.
Сотрудник сдал его за 4 рабочих дня, т.е. затратил 32 часа.
40 - 32 = 8 часов разницы.
Все вполне измеримо и прозрачно.
Для свободной охоты - да.
Для отдыха - только если руководитель понимает, что через те самые 8 часов будет проект высокой сложности.
Такое редко, но бывает.
Хотя опять же, пока никто не жаловался, что обучение не дает отдохнуть.
Мозг переключается, дедлайна нет, можно пить кофе или слушать лекцию на прогулке в парке.
Обучение - это не всегда написание кода.
Попробую перефразировать.
Компания готова выкупать права на хорошие pet-проекты сотрудников.
Возможно так стало понятнее :)
Стесняюсь спросить,
а вы зачем ссылки на ютуб прикрепляете в коменте своем на каждое слово?
Цитируемость поднимаете? :)
Частично с вами соглашусь.
Действительно, джунов с ожиданиями по ЗП как у мидлов - прорва.
Ожидания "входа в ИТ" начинаются от 150к, даже если это интерн полный, которого еще учить и учить.
Но не всегда дело в этом.
Еще бывает:
1) Нецелевой стэк технологий.
Если вы умете в Java, а нужен С++, то вы не нужны.
Если в компании используется фрейм 1, а вы знаете фрейм 2, то вас не возьмут.
Никто не хочет вкладываться в обучение сотрудника, потому что есть страх "обучится и уйдет".
2) HR со странностями.
Данный персонаж оценивает соискателя не по навыкам,
а по тому, нравитесь вы ему или нет.
Половину вопросов такой HR не понимает, другую половину перефразирует во что-то типа
"HTML знаете?
Вот вам листочек - напишите страницу"
или
"Java знаете? Значит JavaScript вам близок" :)
3) Руководитель с детской травмой.
Тоже встречается на просторах вселенной случай, когда руководитель боится брать более скилловых подчиненных.
На мой взгляд должно быть наоборот, ведь руководитель по определению "широкий спец", который "в глубину" не умеет, у него задачи другие.
Вот и получается, что он набирает "слабеньких", чтоб на их фоне быть "умным".
В этом случае, чем выше ваш уровень - тем ниже шанс быть принятым на работу.
С тем, что сотрудник должен приносить прибыль компании никто никогда не спорил.
Цель существования любой компании - извлечение прибыли.
Вопрос лишь в том, используется ли сотрудник "как расходник"
или это "самый ценный актив компании".
А вот тут мнения у всех расходятся )
Как пример Япония, где люди на работе умирают, а экономика не особо то и в рост идет сейчас.
Как я писал выше, у сотрудника появляется период, когда новая задача еще не пришла и в этот период у него то, что у нас называется "свободная охота".
Сотрудник изучает то, что ему интересно и имеет потенциальную пользу где-то позже в проектах.
Иногда, проект сразу не приходит и состояние "охоты" может длиться порядка недели.
С какой целью занижать интенсивность, если после окончания проекта никто ничего "не накидывает"?
Как раз интенсивность идет в рост, так как сотрудник понимает, что может обеспечить себе легальную "свободную охоту", а это сразу означает отсутствие дедлайнов и пушей в git.
Бизнесу выгодно "заканчивать проекты", чем их будет больше завершено - тем выше прибыль.
И снижать стоимость поддержки тоже выгодно, а это достигается качеством кода.
Т.е. давая обучаться мы снижаем расходы, как я и писал выше.
И да, и нет.
Мы изначально планируем времязатраты так, чтоб у сотрудника было примерно 20% времени на изучение дополнительных материалов.
Загнать сотрудника в рутину "делай-делай" - это прямой путь к выгоранию и увольнению.
Т.е. если заказов приходит больше, чем способна вытянуть команда, то это повод задуматься о "горизонтальном расширении" как раз, у нас такое уже случалось.
"Выжигать людей" - порочная практика хотя бы потому, что следом вы получите "-1" качественный сотрудник и "+1" человек в обучение, что явно выйдет дороже.
Как раз далее в статье написано, что в мире IT вариант LB сложно реализуем и требуется переход к WLB.
Сам концепт WLB не дает выгорания, потому что работа становится не рутиной с 9 до 18, а процессом внутри жизни.
Работа становится высокооплачиваемым хобби, если так удобнее воспринимать.
Тут сразу оговорюсь, что если сотрудник попал "по ошибке" в IT, то для него такой режим станет каторгой :)
Юридические детали раскрывать не буду, но суть сводится к тому, что хорошие задумки становятся собственностью компании юридически, на них передаются полные права.
Торговаться у нас не принято - это потеря времени.
Нужно что-то, сотрудник озвучивает и далее пытаемся решить вопрос.
Если он решаемый - соглашаемся.
Если нет - предлагаем варианты и думаем далее.
В частности, так решается вопрос платного доступа к тематическим ресурсам, например.
Выгода разработчика - проект может получить инвестирование в разработку и улучшение, если докажет жизнеспособность.
Однако, если разработчик хочет, может разрабатывать самостоятельно без передачи прав - никто мешать не будет.
Важно понимать, что большинство проектов "в одиночку" не делаются, а если и делаются, то заканчиваются в git open sourse без финансовой выгоды для разработчика.
Слишком много человеко-часов требуется, чтоб создать хотя бы MVP.
А следом идет внедрение, переговоры с потенциальными заказчиками и т.п.
Следом требуется UI/UX перенастройки под фокус группы, CI/CD и расчет мощностей и прочее.
Ни один человек не в силах изучить все, к сожалению.
Т.е. сотрудник превращается из разработчика в гендира с командой узких спецов и забывает про код.
Про LB и WLB можно забыть, это фактически запуск бизнеса с нуля.
Ну и про конфликт интересов не нужно забывать.
Мы же нанимаем разработчика, а не стартапера со своей независимой командой :)
Из нашей практики мало кто хочет менять профиль ради идеи,
которая не факт, что "выстрелит".
А компания как раз берет на себя этот риск, ей выгодно, чтоб идея сработала.
При этом разработчик рад тому, что идея жизнеспособна и над ней можно работать далее, развивая ее в рабочее время.
Надеюсь правильно понял ваши вопросы :)
Если расскажете чуть подробнее о вашем стеке и фреймворке - возможно,
что смогу дать рекомендации.
Но самое вероятное - ваш стек "узкий" и как итог компаний, которые готовы вас принять, будет не очень много и в них высокий порог входа.
Как пример,
для ООО "Ромашка" у вас не хватает навыков из смежных областей (там часто хотят кросс-возможности, например фулл-стек, бек + DevOps и т.п.),
а для IBM у вас не хватает уровня - им нужны узкопрофильные Боги Разработки.
Вот и получается "мертвая долина", где, вроде бы навыки у вас есть, но ощущение, что они никому не нужны.
Спасибо за вопрос.
Если мы говорим о внешнем заказчике, то по сути он заказывает не часы работы,
а "услугу по разработке", иначе это уже аутсорс получается.
В этом случае окончание работ "до срока" - это прямая выгода РМ компании разработчика, так как сотрудники потенциально могут заняться другими проектами, т.е. приносить прибыль.
Справедливости ради, обычно возникает пауза хотя бы дня в 3 между ними, т.е. "есть время обучению".
Даже если разработчики 2 недели будут просто заниматься обучением - это уменьшит срок старта и затраты на эксплуатацию новых проектов, т.е. будет наблюдаться эффект отложенной прибыли.
А еще это дает хорошие гарантии того, что "проект успешно сдан",
поскольку остается время на дебаг, если он возникнет.
Т.е. PM закрывает свой KPI с гарантией и это ему выгодно.
Ну и никакого выгорания, все понимают, что укладываются в сроки.
Если заказчик получает продукт раньше срока, то он может начать ускорять остальные процессы.
В моей практике все заказчики коммерческого сектора приходят с запросами "нужно было вчера, чем быстрее - тем лучше".
Отсюда и вывод, что им это тоже выгодно.
Если под "идея дать денег разработчику" подразумевается премия, то она тоже выписывается, но реже.
Мы предпочитаем индексирование ЗП - это эффективнее и понятнее.
По крайней мере у нас всех устраивает такой подход :)
Спасибо за вопрос.
Исхожу из того, как это работает у нас в компании и этот подход финансово обоснован, кстати.
Действительно, бизнес - это извлечение прибыли.
Однако, если владелец заточен строго на прибыль, а не на расширение бизнеса, то с высокой долей вероятности такой бизнес схлопнется со временем.
Владелец просто "обескровит" бизнес, забрав прибыль.
Если говорить о разработке, то инвестиция в бизнес там может быть лишь в ширину или в глубину.
Я сейчас не о продажах, а именно о разработке и разработчиках.
Ширина - это "раздуть" штат.
Глубина - это улучшить навыки тех, кто уже есть, чтоб работы производились лучше и быстрее.
Опыт стартапов показывает, что "ширина" быстро выедает бюджет.
И создает "токсичность", ведь все примерно равны в навыках и пытаются доказать друг-другу, кто круче.
Следом начинают требоваться тимлиды, которые тоже требуют ЗП и т.п.
Т.е. расходная часть растет очень быстро.
В отличии от "глубины".
Она позволяет делать продукт качественнее, снижая его стартовые и эксплуатационные расходы.
Там где сотрудник делал 1 продукт за месяц он начинает собирать тот же продукт за 2 недели.
При этом нет "притирочных" периодов, потому что не меняется штат.
Далее, когда придет новый сотрудник, его не будут "токсить", а помогут быстро адаптироваться сами разработчики, потому что новый сотрудник никакой угрозы им не представляет с точки зрения навыков.
Таким образом, если новые проекты приходят,
то сотрудники спокойно работают без горящих дедлайнов.
Соответственно и выгорать перестают.
А свободное время легально уходит на "свои интересы", что снижает уровень недоверия.
Или "на личные проекты", что тоже весьма интересно, ведь в это случае они являются архитекторами этого проекта, который далее можно будет развивать совместно с бизнесом.
Здесь нужно понимать, что удачные проекты бизнес в любом случае будет пытаться развить и "одиночки разработчики" нормальный проект не создадут, только в команде.
Это длительный процесс.
По PR - согласен.
Однако, лично у меня были ожидания новых продуктов, которые не оправдались.
Отсюда и статья о "странных" трендах.
Спасибо за комментарий.
Ваша мысль передана грубо, но мне понятна.
Однако, если вы пообщаетесь с HR, то поймете, что они действительно верят в то, что делают.
Я бы назвал это некоторым заблуждением с их стороны, когда вера в то, что "игра работает" доминирует над реальностью. А раз никто не дает отрицательных отзывов (запрещено, на это же средства были выделены) - значит все работает отлично.
Касательно подмены понятий "специалист" и "обслуга" - не соглашусь.
Не так давно мы искали разработчика.
Удалось найти нужный уровень кандидате лишь на 30-ом человеке.
Очень много тех, кто 3 дня учил язык на вебинарах и теперь хочет 300 000 в месяц.
Если честно, то не очень понял, что вы имели ввиду.
Попробуйте перефразировать
Спасибо за комментарий.
Основная мысль тезисов в том, что понятные и прозрачные критерии, нам мой взгляд, пытаются заменить на непонятную виртуальную вселенную.
И, видимо, это уже намеченный тренд.
Из моей практики такой подход не работает.
Заработная плата "в рынке" - это гигиенический фактор, он просто должен быть.
Если работодатель платит ниже рынка, то он должен быть готов к оттоку высококлассных кадров.
Удерживать сотрудника "вечно" даже при идеальных условиях сложно,
а при низкой ЗП - это просто "карусель кадров".
Однако и давать "плюшки" без достижений - тоже не стоит.
Это порождает кадровую инфляцию.
Те самые 5 офферов за год :)
И как итог появляется тот самый "рынок соискателя", который плох и для соискателя, тоже.
а) Вместо развития компании начинают вкидывать деньги в заработные платы,
б) которые провоцируют реальную инфляцию,
в) которая обесценивает высокую заработную плату,
г) как итог услуги компании становятся менее востребованы,
д) что ведет к сокращению штата,
е) что может привести к увольнению
По удаленке, да, наверное стоит давать выбор.
Согласен с утверждением
Как и обещал, внес правку в статью и указал вас, как автора правки.
Еще раз спасибо :)
Как раз такая система использовалась "в базе", происходил подлог меток или передача сменщику, чтоб пробил.
Как итог на объекте 1 человек, а ЗП получат два.
При этом проверять "онлайн" всех по камерам заказчик не может в силу финансовых затрат.
Объектов очень много
Спасибо за ваш интерес к статье и комментарий.
На самом деле уже планируется к выпуску вторая часть, которая будет опираться строго на документацию самого ЦБ, как первоисточника инновации.
Можно назвать эту часть "Цифровой рубль по версии СМИ и техно-блогов",
посмотрим сойдется ли описание с описанием самого ЦБ во второй части "Цифровой рубль глазами разработчика".
Уже, на этапе сбора материалов, вижу, что есть некоторые интересные расхождения.
Плюс добавится сводная таблица для удобства чтения данных.
А как оно будет реально запущено - узнаем в середине 2025 года :)
К сожалению не вышло бы )
Фарма, провизоры.
Они постоянно в движении и практически не сидят.
Собственно потому и возник кейс у заказчика