Как стать автором
Обновить

Комментарии 17

материал из разряда пропаганды "теории малых дел"

почему не заданы вопросы:

почему компания хочет команду но никогда не закладывает ресурсов на построение этой самой команды?

почему компания не ограждает исполнителей от заказчиков без внятного тз?

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

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

все считают что построение культуры командной работы это побочный эффект работы...нет это тоже работа и на неё нужно тратить временные ресурсы

Этот материал скорее про отношения человек-человек, а не бизнес-человек.

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

НЛО прилетело и опубликовало эту надпись здесь

Ну если у разработчиков есть в этом бизнесе доля сообразная вкладываемым в бизнес ресурсам, то делать на благо бизнеса - вполне рабочая схема. А если "взбивайте общие сливки, нам масло, вам сыворотка", то идея "чуть-чуть вредить", становится всё более привлекательной со временем.

НЛО прилетело и опубликовало эту надпись здесь

Советы от эффективных менеджеров как нам выполнять хорошо свою работу?

Волки из пацанских пабликов. Докатились.

НЛО прилетело и опубликовало эту надпись здесь
Это ж постирония) (правда, уже баянистая)
image

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

С одной стороны, за такое надо просто увольнять. С другой - если система настроена правильно, то к задаче (заявке, тикету - в разных системах разное название), должен подвязаться твой PullRequest. Или, нет PullRequest-а - нельзя задачу закрыть. Как то так.

Верно. Никто не заставляет углубляться в виды дизайна или учить другие языки разработки. Но пригодится знать, как устроена работа коллег в соседних командах: это сэкономит время на переговорах. 

Что то ни разу не видел, что бы дизайнер, HR, бухгалтер или вообще кто поинтересовались - как устроена работа у программистов. В основном всё общение происходит на совещаниях. Например, недавно дизайнер хотел изменить окно в браузере, которое отвечает за авторизацию в домене.


P.S. Дальше читать уже сил не было, оценка -6 сама за себя говорит

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

Согласна, вопрос работает в обе стороны. Это задача для статей на других ресурсах для дизайнеров, эйчаров и программистов)

Спасибо за мнение!

НЛО прилетело и опубликовало эту надпись здесь

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

Плохо

Я знаю, что так будет лучше. Я читал в учебнике.

Хорошо

Лучше выкатить … после …, потому что однажды одна компания сделала наоборот — и всё упало. То, что вы предлагаете, проще и быстрее, но, мне кажется, мы рискуем.

Тут обе вещи плохо. Если однажды компания сделала наоборот и все упало, то дело может быть не в идее, а в реализации. А в учебниках может быть описана world best practice, просто опять таки реализовывать ее надо с пониманием.

Во-вторых почти все проблемы указанные в статье, особенно касающиеся замалчивания - относятся не к разработчикам, а к менеджерам младшего и среднего звена. А то и старшего. Я не помню, чтобы разработчики о чем-то умалчивали. Наоборот регулярно доносят наверх о существующих технических проблемах и накапливающемся техническом долге, из-за которого повышаются риски багов. Но менеджеру нужно отчитаться заказчику о выполненных бизнес-задачах, поэтому все техническое замалчивается и заметывается под коврик. Но это делают МЕНЕДЖЕРЫ, а не разработчики.

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

капасити на курирование джунов могут выделить только менеджеры

капасити на правильный code-review могут выделить только менеджеры

проактивность без капасити невозможна, проактивность без поддержки со стороны менеджеров невозможна. Я работал в проекте, где за проактивность могли дать премию, если она проходила определенный этап ревью. За год от нашей команды было подано около 400 идей, из которых за 18 получили премию. А без этого, откуда взяться проактивности?

Разработчик - имеет очень мало прав. В одной компании у нас в коридоре был турник, и мы почти всей командой разработчиков на нем регулярно занимались. Потом в компании случились перестановки, мы переехали в другой блок здания, где не было турника. Мы просили компанию организовать (стоимость такого турника ничтожна, мы его и сами бы купили и сами бы установили), но компания не позволяла. Нас было 12 человек разработчиков, проактивных. И только через пол года активных переговоров и переписок нам позволили организовать турник. Купили stand-alone, поставили прямо в кабинете.

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

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

Спасибо за историю! Это негативный, но крутой реалистичный кейс. Компании и правда разные, руководство бывает разное.

Сохранила ваш комментарий, чтобы пофиксить ошибки в будущих материалах.

В статье можно заменить "разработчик" на любую другую роль в команде - и общий посыл ни на йоту не изменится. Потому что должна быть синергия и взаимопроникновение опыта. Что бывает редко.

Но я не вижу статей вроде "как стать отличным аналитиком и начать писать ТЗ, а не филькины грамоты". Вместо этого зачастили статьи, где учат жить разрабов, причем довольно топорно.

Выходить за рамки настолько, чтобы полноценно заменять функции коллег — не круто, согласна. Тут уже задача бизнеса — оградить сотрудников от этого. Или задача сотрудника — отстоять свои границы или найти новое место.

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий