никому не двигаться, всё на контроле

если в начале проекта руководитель обычно расчитывает на «решение проблем по мере их поступления» или «пока работаем как есть, потом настроим процесс», то пару раз поев говна лягушек он же ударяется в бесконечный контроль, процесс, соглас и микроменеджмент.

коротко, как угробить проект системой и процессами:

кейс А - после провального тестирования новой фичи вводят правило о прилюдной демонстрации любых скриптов/миграций перед релизом на аудиторию ответсвенных лиц. результат - три сорванных на несколько дней релизов подряд, и все еще дефект на проде)

причина - неверно определен уровень проблемы. процесс был поставлен на контроль некорректным ролям, тестирование не улучшилось. длительный процесс согласования демонстрации внес дополнительную суету, замедлив разработку и проблему в итоге не решив.

правильное решение - разработка регламента тестирования, подключение аналитиков для подготовки тест-кейсов перед релизом.

кейс B - при интеграции со смежной командой не было актуального описания API системы. было принято решение документировать во внешней базе знаний КАЖДЫЙ ВОЗМОЖНЫЙ ЗАПРОС в системе из 10+ сервисов, результат - дополнительные 5-10% времени на каждую задачу, где есть взаимодействие по сети. изначальная проблема решена, однако наблюдается явный оверхэд - 9 из 10 сервисов предназначены для внутреннего использования, никакая другая команда подключаться к ним не будет (да и не просит). как итог, проблема потраченного времени на аналитику изначальной проблемы теперь закреплена официально и надолго.

причина - технический лидер не учитывает ресурсные возможности команды. его задача поддерживать техническое совершенство проекта, а не подгонять возможности под бюджеты и сроки.

правильное решение - документировать один сервис, пересмотреть зоны ответственности лиц принимающих решения, расширять компетенции спецов для более широкого взгляда на проблему.

пожалуйста, не убивайтесь насмерть о регламенты и контроль, ваша команда нанята не за красивые глазы, им можно доверять)
лучше расширяйте их зоны ответственности (только сначала им об этом расскажите, а лучше и сами зоны пропишите текстом).

с какими мрачными вариантами микроменеджмента вы сталкивались в своей компании/команде? пишите в комментариях

все-никак-не-начинающие специалисты

вот тут автор обратил внимание на высокий порог входа в айтишечке и бесконечную очередь из джунов на вакансии. данный пост является исключительно размышлениями по теме.

проблема недоквалифицированных кадров чрезмерно раздута в современных реалиях. по ощущениям, мир капитально недооценивает джунов и уровень компетенций, необходимый для работы. 80% задач в современном программировании это условное «перекладывание жсонов», только 20% алгоритмических/инфры/техзадач - работенка для сеньоров. но при этом соответствующего баланса в спецах практически нигде не наблюдается: в большинстве контор мечтают о берут двух сеньоров, каждый из которых считает себя «слишком крутым спецом, чтобы перекладывать жсоны» и в итоге растягивает часовую задачу на три дня.

неумелый жун же в свою очередь (да, пусть и заебав насмерть задав тысячу вопросов) потратит по итогу два дня. день выигран, продакт счастлив!

ответственность за «пробку из джунов» лежит увы не только на отвратном госушном образовании и скиллбоксе, но и на нас с вами:

- сеньорах, которые не хотят заниматься молодыми спецами;
- конторах, которые не хотят потратить два-три месяца (!!!) на то чтобы ввести человека по нормальному в проект;
- начальниках и эйчарах, которые ставят фильтры на опыт в резюме, и просто выкидывают на обочину толпу талантливых ребят даже не взглянув.

скачок от уровня джун- до миддл происходит гораздо быстрее чем кажется, джуны гораздо более замотивированны работать, сильнее лояльны компании.

а если вдруг ваш «начинающий специалист» дропнул бл на проде, то перепроверьте, вы точно не поленились потратить 5 минут на человека, вместо того чтобы пульнуть в него статью на хабре?

p.s.: не уверен, работают ли комменты😁

решил в полурекламных целях написать статейку на vc.ru, о том как на коленке организовывать разработку, если вы никогда ее не организовывали: https://vc.ru/dev/1103027-kak-organizovat-pogromistov-esli-vy-nu-sovsem-ne-razrabotchik

буду благодарен за любое внимание, уделенное вашему покорному

человеческий ресурс

сегодня формат проповеди.

в продолжение темы джунов и внимательного отношения к сотрудникам, хочу поговорить и о всех остальных.

проблемы:
- выгорание;
- текучка кадров;
- «тихие увольнения»;
- слабый work-life-balance;
- и даже промышленный шпионаж.

причина:
отношение к человеческим существам как к человеческим ресурсам (Human Resources выбрали себе название даже не скрываясь).

отношение к ведению бизнеса и работы из оперы «мы тут деньги зарабатываем вапщета» это конечно логично, рационально, удобно и резонно…

но абсолютно бездушно.

у человеческих ресурсов есть график, стоимость и условия по ТК. у человеческих существ - мог в аварии погибнуть ребенок, начаться кризис самоопределения, да просто крутить живот вторые сутки, и при всем при этом не хватать денег на аренду жилья. попробуйте взять отгул, когда лишние 2500 тысячи это разница между есть еда/ нет еды.

на размышления о сочувствии к ближнему меня натолкнула недавняя статья про пельмени на vc.ru, где человек платит сотрудникам из расчета «35к в месяц за пятидневку с 7 до 16», и жалуется, что его производство будет убыточным при повышении зарплат.

как быть? посмотреть правде в глаза и закрывать такое производство, оно просто не рентабельно. кстати, автор в своей статье в итоге вносит воровство в отдельную статью расходов(!!!), так как людей не устраивают условия труда. это никак не оправдывает поведение ворующих, но не снимает ответственность с человека, формирующего условия работы.

причина убыточности большинства бизнесов не в плохих сотрудниках, а в плохих управляющих. в корпорациях это может доходить до абсурда, как недавно произошло с западным IT-сектором и тысячами уволенных для «сокращения расходов».

естесственно, никто не обязан жить себе в убыток чтобы нести добро в этот мир, но если для личного благополучия вам приходится буквально обворовывать других людей (а лично я считаю, что если прибыль на сотрудника составляет больше 25% от выручки на сотрудника - то ваша этическая обязанность если не платить ему больше, то хотя бы дать об этом знать), то пора пересмотреть финансовую модель вашего предприятия.

вкладывайтесь в людей, не в ресурсы/комптенции/должности, а в боевых товарищей. если сегодня вы поможете сотруднику, которого надо две недели подержать в убыток, то не удивляйтесь, когда он согласится в трудный месяц две недели подождать зарплату. потратьте время на обучение сотрудника - получите будущего руководителя. простые вещи, некоторые крупные компании это уже поняли, а остальные просто делают вид, играя в Индивдуальные Планы Развития которые заполняются для отчетности и «повышение зарплаты раз в полгода», которое не догоняет инфляцию.

в современных реалиях люди представляются для компаний цифрами, бланками и KPI. корпоративная культура насквозь провоняла лицемерием, с целью удержать сотрудников, которым компания откровенно не доплачивает. но как-то только настанут трудные времена - они первыми полетят с «парахода современности».

потому что на текущий момент, компания «не может себе позволить такой объем человеческих ресурсов».

p.s.: подумываю назвать у себя отдел HR отделом HD (Human Development)

p.p.s.: и нет, меня ни разу не увольняли)

бесплатные правки

в догонку к сегодняшней проповеди, немного про дела земные.

новый тренд в малом бизнесе/самозанятости - это слать клиентов нахер, желательно так громко, чтобы они от испуга срочно покупали вашу услугу/продукт, а не то загрызут. как найти правильный баланс между правками, которые длятся дольше чем проект, и «звонок после сдачи проекта платный, 5000 за каждую правку»?

я для себя выработал схему с периодом правок: после сдачи проекта оговаривается срок бесплатной поддержки и исправления дефектов, масштаб функциональности, которую можно поменять в этот период также обсуждаем.

плюсы подхода:
- условно бесплатная плюшка для клиента, хоть никто и не мешает вам заложить это в стоимость проекта;
- повышение лояльности, так как вы ответственный исполнитель/компания и за свою работу отвечаете;
- абсолютно резонное требование по оплате правок после окончания периода с вашей стороны;
- процесс гибче чем с кругами правок, так как есть время на обсуждение и в процессе от каких-то моментов можно будет отказаться, а какие-то добавить, но это скорее плюс для клиента.

минусы подхода:
- выдергивать сотрудников на поддержку все еще придется, либо держать в штате линию поддержки;
- маржа немного падает, но с лихвой компенсируется рекомендациями по сарафану;
- все еще немного нужно тормозить клиентов, если они решают за месяц на поддержке переписать сервис с нуля.

кстати, вот эти ребята (Пиробайт) практикуют такой подход, у них 6 месяцев бесплатной поддержки по завершению проекта. на лояльность клиентов не жалуются)

тяни-не-толкай

какая бы гибкая методология не применялась в вашей команде, определенное «этапирование» разработки все равно останется (потому что вы в России, гы).

обычно связка выглядит как бизнес анализ -> системный анализ -> разработка -> тестирование -> релиз; неудачное выполнение одного из этапов сдвигает процесс на несколько шагов назад (привет, agile). но если где-то в цепочке появилась пауза, встает все, что идет после, человек на стопорящем этапе начинает закапываться, увеличивает пробку и так далее до банкротства.

проблема: низкая утилизация возможностей команды, много простоев.

решение: переход на pull-модель.

придумка не моя, но работает здорово: вместо того, чтобы спускать задачи от первого этапа ко второму, второй тянет задачи у первого. определенное количество простоев все еще может образовываться, но ситуация когда «бутылочное горлышко» закупоривается валом задач исчезает. такой подход позволяет если не избавиться от проблемы целиком, то хотя бы не доводить ее до состояния, когда на решение нет времени ибо все горит.

где-то видел исследование (которое естественно не найду) что при переходе на такую систему утилизация ресурсов сотрудников вырастала почти вдвое. для настолько элементарной эвристики результат хорош.

p.s.: собрал себе табличку, чтобы посчитать идеальную бизнес-модель своего агентства, циферки обнадеживающие, рентабельность в районе 25% выглядит более чем реально