ME
пуфон ♥
Захотелось раскрыть мысль и немного пографоманить
У компании есть прозрачные цели: заработать деньги, захватить рынок, сделать образование доступным, быть этичным по отношению к сотрудникам, етц. В классных компаниях эти цели понятны и видны всем, и техписам, и девопсам, и C-level, и линейным менеджерам.
Когда я, как разработчик, делаю какую-нибудь штуку, я искренне уверен в своей правоте: говнокодить нельзя, код должен быть чистым, архитектура правильной, а вот эту фичу мы делать не будем, потому что она нехорошая. У продаковнера точно такая же своя правота, у техписа своя, у QA своя. В условиях неограниченных ресурсов мы бы все были друг другом довольны, но в условиях ограниченных — нам постоянно приходится чем-то жертвовать.
Когда в компании есть прозрачные цели, то любое решение можно приложить к этому компасу и попытаться понять, насколько это новое решение нас двигает в ту сторону. Продакт-овнер просит срезать углы и сделать говнокод? Но ведь мы потом никого нанять на этот проект не сможем, и всё равно переписывать. Фича нужна завтра и мы без неё потеряем тысячи долларов? Сделаем сейчас абы как, но в следующую неделю исправим.
С этим есть пара проблем:
- иногда результат нового решения может казаться слишком туманным: так никто не делал, мы такое не считали, может как хорошо повлиять, так и плохо — такие идеи никогда не пройдут проверку компасом, а часто именно они и являются прорывными
- если идея слишком простая или однобокая (только "заработать денег", например), то очень многие решения придётся проворачивать через "через пять лет это начнёт отнимать у нас деньги"
С первой проблемой можно бороться экспериментами на ограниченном флоу — если автор вопроса предложит "мне очень больно, но я не уверен насколько документация решит мою боль. Давайте разработчики два спринта будут писать документацию, а потом мы соберёмся и обсудим насколько это ок?".
Такие эксперименты всегда дешевле чем принять идею навсегда. Проводить стендап стоя целый спринт. Запустить микросервис на новой технологии. На неделю сократить количество серверов вдвое. Месяц выделять один день в неделю на технический долг. А ещё эксперименты оставляют большой простор для ошибок — а вдруг окажется, что документация это вообще не то, что искал автор?
В моей текущей команде мы большинство командных изменений проводим экспериментами. (лайфхак — в семье я пользуюсь той же тактикой)
Со второй проблемой чуть сложнее. Она требует не просто создания сложного "компаса", но и синхронизации его сразу у многих людей в компании. Я привык называть этот компас культурой компании, и для меня он не только про бизнес-решения, но и про корпоративные решения: с кем на вы, а с кем на ты; можно ли агрессивно троллить; в каком виде приходит критика; как ставятся задачи.
Как на него влиять — хз, на это нужен гигантский ресурс, но это реально даже не на менеджерских позициях (личный опыт). Но когда этот компас есть и он работает, и в компании есть много разных ролей, каждая из которых тянет одеяло в свою сторону, то это прям кайфы
