Comments 17
материал из разряда пропаганды "теории малых дел"
почему не заданы вопросы:
почему компания хочет команду но никогда не закладывает ресурсов на построение этой самой команды?
почему компания не ограждает исполнителей от заказчиков без внятного тз?
почему компании говорят о важности общения в команде но тут же забывают о солидарности внутри этой команды относительно харасмента, увольнения?
рыба гниёт с головы, чистят её с хвоста...проблема команд лежит на 99% в рамках требований тех, кто платит зарплату и эти требования как раз и мешают разработчикам создавать нормальные команды но вопрос в статье рассматривается сугубо с "хвоста"
все считают что построение культуры командной работы это побочный эффект работы...нет это тоже работа и на неё нужно тратить временные ресурсы
Этот материал скорее про отношения человек-человек, а не бизнес-человек.
То, о чем вы пишете — тезисы для отдельной статьи. Про то, почему компания должна следить за климатом в команде, где ошибается бизнес, почему не выделяет ресурсы на выстраивание командных процессов и к каким проблемам это приводит. И это хорошая идея, спасибо вам за критику)
Советы от эффективных менеджеров как нам выполнять хорошо свою работу?
Волки из пацанских пабликов. Докатились.
Никому не сказать, закрыть задачу, потому что нет времени что-то исправлять.
С одной стороны, за такое надо просто увольнять. С другой - если система настроена правильно, то к задаче (заявке, тикету - в разных системах разное название), должен подвязаться твой PullRequest. Или, нет PullRequest-а - нельзя задачу закрыть. Как то так.
Верно. Никто не заставляет углубляться в виды дизайна или учить другие языки разработки. Но пригодится знать, как устроена работа коллег в соседних командах: это сэкономит время на переговорах.
Что то ни разу не видел, что бы дизайнер, HR, бухгалтер или вообще кто поинтересовались - как устроена работа у программистов. В основном всё общение происходит на совещаниях. Например, недавно дизайнер хотел изменить окно в браузере, которое отвечает за авторизацию в домене.
P.S. Дальше читать уже сил не было, оценка -6 сама за себя говорит
Очень правильные мысли в статье, очень жаль коллег которые с такими комментариями приходят.
❌ Плохо
Я знаю, что так будет лучше. Я читал в учебнике.
✅ Хорошо
Лучше выкатить … после …, потому что однажды одна компания сделала наоборот — и всё упало. То, что вы предлагаете, проще и быстрее, но, мне кажется, мы рискуем.
Тут обе вещи плохо. Если однажды компания сделала наоборот и все упало, то дело может быть не в идее, а в реализации. А в учебниках может быть описана world best practice, просто опять таки реализовывать ее надо с пониманием.
Во-вторых почти все проблемы указанные в статье, особенно касающиеся замалчивания - относятся не к разработчикам, а к менеджерам младшего и среднего звена. А то и старшего. Я не помню, чтобы разработчики о чем-то умалчивали. Наоборот регулярно доносят наверх о существующих технических проблемах и накапливающемся техническом долге, из-за которого повышаются риски багов. Но менеджеру нужно отчитаться заказчику о выполненных бизнес-задачах, поэтому все техническое замалчивается и заметывается под коврик. Но это делают МЕНЕДЖЕРЫ, а не разработчики.
капасити на технические задачи могут выделить только менеджеры
капасити на курирование джунов могут выделить только менеджеры
капасити на правильный code-review могут выделить только менеджеры
проактивность без капасити невозможна, проактивность без поддержки со стороны менеджеров невозможна. Я работал в проекте, где за проактивность могли дать премию, если она проходила определенный этап ревью. За год от нашей команды было подано около 400 идей, из которых за 18 получили премию. А без этого, откуда взяться проактивности?
Разработчик - имеет очень мало прав. В одной компании у нас в коридоре был турник, и мы почти всей командой разработчиков на нем регулярно занимались. Потом в компании случились перестановки, мы переехали в другой блок здания, где не было турника. Мы просили компанию организовать (стоимость такого турника ничтожна, мы его и сами бы купили и сами бы установили), но компания не позволяла. Нас было 12 человек разработчиков, проактивных. И только через пол года активных переговоров и переписок нам позволили организовать турник. Купили stand-alone, поставили прямо в кабинете.
И это еще про-активность, которая была очень мотивирована, еще и поддерживалась дайрект менеджером, но рубилась чуть выше, и совершенно не понятно почему рубилась - никому от этого не было бы плохо.
В общем все эти советы давать разработчикам бессмысленно. Просто читаешь как сказочку о том, как в какой-то волшебной компании есть волшебные менеджеры, и тогда все это заработает и без этих советов.
В статье можно заменить "разработчик" на любую другую роль в команде - и общий посыл ни на йоту не изменится. Потому что должна быть синергия и взаимопроникновение опыта. Что бывает редко.
Но я не вижу статей вроде "как стать отличным аналитиком и начать писать ТЗ, а не филькины грамоты". Вместо этого зачастили статьи, где учат жить разрабов, причем довольно топорно.
Выходить за рамки настолько, чтобы полноценно заменять функции коллег — не круто, согласна. Тут уже задача бизнеса — оградить сотрудников от этого. Или задача сотрудника — отстоять свои границы или найти новое место.
Знания помогают только говорить на одном языке и понимать, что от тебя требуют. Но каждый должен заниматься своей работой.
Что нужно, чтобы стать отличным разработчиком