Пару недель назад был на экскурсии в партизанских тоннелях во Вьетнаме, по дороге нас завезли на фабрику, где работают инвалиды с мутациями (там за пятикратную цену можно было купить всякие поделки, ну типа помогите жертвам войны). Реально там шестипалые, безногие и с другими странными конечностями люди, сидят, делают всякие картинки, горшочки.
В общем, вся эта высокотехнологичная война — это очень грустно :(
Коля, а право на название «Аскозия» вам передали вместе со статусом дистрибьютора или были какие-то юридические действия?
ps: имена с телефонами на скриншоте я бы изменил, а то приватность же ;)
Я вот однажды переписал у одноклассника игру (Warcraft 2 или что-то подобное) на дискетах. Они ещё удобно продавались и потом хранились в таких картонных коробочках, как сейчас помню, 28 дискет.
Записываешь всё это, садишься в автобус, едешь на другой конец города, и копируешь к себе на комп. Пара дискет глючит, ты запоминаешь номера файлов, садишься на автобус, едешь на другой конец города, записываешь эти файлы уже дублируя дискеты…
В третьих Героях ещё вся музыка лежала в отдельной папке в mp3-файлах.
Когда прекрасная оригинальная музыка наскучила, мы с женой с удовольствием подобрали плейлист из модного тогда атмосферного джангла под каждый замок, и Герои заиграли новыми красками.
Никогда даже близко не испытывал кайфа и удовлетворения от комментирования плохого кода. Наоборот, меня это искренне расстраивает, потому что каждый хреновый пул реквест — это в первую очередь показатель того, как работает команда, в которой я — тимлид.
Если я вижу существенные недостатки в работе разработчика, это означает, что теперь мне нужно потратить время на их фиксацию, на разъяснения, потом мне придётся потратить время на переключение обратно в свою работу, а ему придётся потратить время на исправление проблем, на преодоление негатива и так далее, и тому подобное.
И всё это время — это чистые издержки. Поэтому я вообще не понимаю, как в этой ситуации можно находить повод для самоутверждения. Если в твоей команде люди делают говно, это значит что ты сам плохо работаешь.
Да даже задачи могут ставить разные люди, это не проблема, если они ставят их в едином формате в одной системе, ведут общее планирование и не перекладывают ответственность за приоретизацию на исполнителя.
По вашему опыту одно, а по моему опыту другое. Любая оргструктура, как и любая методология, имеют свои сильные и слабые стороны, что-то лучше работает в одном случае, что-то в другом. Поэтому любые общие утверждения на этот счёт всегда вызывают улыбку.
Что касается «совмещения обязанностей» — такого не будет, потому что у руководителя есть свои рычаги управления. Да, это недостаток матричной структуры — сложность для менеджеров и руководителей, им надо чётко разобраться где чья юрисдикция, им надо много общаться, но здесь и плюсы.
Уж если в компании проектная деятельность (а в айти такое часто, пусть даже это не внешний заказчик), то матричная структура складывается буквально сама собой, потому что даёт фокус на результат проекта, при этом оставляет и традиционную иерархию, привычную и даже требуемую некоторыми отраслевыми стандартами.
Современные представления об управлении считают иначе.
В матричной структуре у разработчика может быть руководитель подразделения (строго говоря, это он и будет «одним руководителем», с которым он будет беседовать про зарплату, отдельный кабинет и повышение квалификации), однако, при этом задачи он будет получать от менеджера проекта и планированием его работ тоже будет заниматься менеджер. И такая система кстати неплохо работает в ряде случаев.
Больше того, сейчас считается модным работать по agile, в котором по определению не будет ТЗ или его заменителя, потому что communication over documentation.
В любом айти-проекте существует множество задач, и не все они связаны с разработкой. Иногда от разработчика требуется что-то пояснить менеджеру, например для того, чтобы он грамотно отбился от претензий заказчика, и дал разработчику спокойно продолжать работу. Плохо, если даже в такой ситуации он говорит менеджеру: «ты тупой, поэтому я тебе ничего не буду объяснять».
Всё правильно говорите. Но я бы добавил, что всё-таки часто проблема на другой стороне. Какой-нибудь заслуженный разработчик видит, что на роль менеджера назначили «девочку» или «мальчика», который никогда не писал промышленный код, и его оскорбляет, что теперь он находится «под началом» какого-то салаги.
Я даже пытался об этом напрямую говорить с некоторыми людьми, как разработчик с разработчиком, но этот стереотип сложно перешагнуть. Такие люди могут просто саботировать работу в новой системе: игнорировать совещания или отмахиваться от любой коммуникации.
Хотя это конечно тоже во многом сфера ответственности нового менеджера, как он сам себя сразу же позиционирует. Это отдельная история.
Таким образом, статья сводится к тезису: «Не нанимайте плохих сотрудников — это плохо скажется на вашем бизнесе. Мы в компании Crossover советуем вам нанимать хороших сотрудников».
Именно так, своими глазами наблюдал как чуть не умерли два проекта, во главе которых был поставлен прекрасный, очень талантливый и деятельный, опытнейший «сеньор», который всё губил техническим перфекционизмом и тщательным огораживанием разработчиков от всякого давления извне. Создавал, вроде как, чудесный мир, где кодеры делают идеальный продукт (веки вечные).
Ну хорошо, «эффективных менеджеров» обсмеяли, но как быть с эффективными менеджерами, они существуют? Они нужны компании? И как их отличить от «эффективных менеджеров», где их найти?
По статье создалось впечатление, что на роль менеджеров нужно брать хороших тимлидов, буквально переводить инженера в чистые руководители. Тут тоже вопросы, во-первых, на кой чёрт человеку с большим опытом и налаженной работой уходить в управление, менять сферу деятельности? Во-вторых, кто вам сказал, что он будет с этим хорошо справляться?
Для правильного понимания современных подходов к управлению разработкой и управлению вообще нужно в первую очередь избавляться от комплекса «подчинённый-начальник». Так, например, не надо все менеджерские позиции считать «начальственными». Не надо требовать от хорошего администратора навыков разработки. Тимлид, и даже рядовой разработчик, ВСЕГДА должен быть более квалифицированным инженером, чем, к примеру, менеджер проекта, потому что каждый должен быть на своём месте и хорошо делать именно свою работу. (И влияние в компании он тоже может иметь значительно большее.)
Вот метрики, взятые с потолка, или разрыв горизонтальных связей в компании — это просто плохо сделанная управленческая работа. Плохой сотрудник он и в Африке плохой, будь он менеджер или инженер.
В общем, вся эта высокотехнологичная война — это очень грустно :(
ps: имена с телефонами на скриншоте я бы изменил, а то приватность же ;)
Записываешь всё это, садишься в автобус, едешь на другой конец города, и копируешь к себе на комп. Пара дискет глючит, ты запоминаешь номера файлов, садишься на автобус, едешь на другой конец города, записываешь эти файлы уже дублируя дискеты…
Когда прекрасная оригинальная музыка наскучила, мы с женой с удовольствием подобрали плейлист из модного тогда атмосферного джангла под каждый замок, и Герои заиграли новыми красками.
Если работаете в одиночку — делайте всё то же самое, что принято делать в команде.
Если я вижу существенные недостатки в работе разработчика, это означает, что теперь мне нужно потратить время на их фиксацию, на разъяснения, потом мне придётся потратить время на переключение обратно в свою работу, а ему придётся потратить время на исправление проблем, на преодоление негатива и так далее, и тому подобное.
И всё это время — это чистые издержки. Поэтому я вообще не понимаю, как в этой ситуации можно находить повод для самоутверждения. Если в твоей команде люди делают говно, это значит что ты сам плохо работаешь.
Что касается «совмещения обязанностей» — такого не будет, потому что у руководителя есть свои рычаги управления. Да, это недостаток матричной структуры — сложность для менеджеров и руководителей, им надо чётко разобраться где чья юрисдикция, им надо много общаться, но здесь и плюсы.
Уж если в компании проектная деятельность (а в айти такое часто, пусть даже это не внешний заказчик), то матричная структура складывается буквально сама собой, потому что даёт фокус на результат проекта, при этом оставляет и традиционную иерархию, привычную и даже требуемую некоторыми отраслевыми стандартами.
В матричной структуре у разработчика может быть руководитель подразделения (строго говоря, это он и будет «одним руководителем», с которым он будет беседовать про зарплату, отдельный кабинет и повышение квалификации), однако, при этом задачи он будет получать от менеджера проекта и планированием его работ тоже будет заниматься менеджер. И такая система кстати неплохо работает в ряде случаев.
Больше того, сейчас считается модным работать по agile, в котором по определению не будет ТЗ или его заменителя, потому что communication over documentation.
Я даже пытался об этом напрямую говорить с некоторыми людьми, как разработчик с разработчиком, но этот стереотип сложно перешагнуть. Такие люди могут просто саботировать работу в новой системе: игнорировать совещания или отмахиваться от любой коммуникации.
Хотя это конечно тоже во многом сфера ответственности нового менеджера, как он сам себя сразу же позиционирует. Это отдельная история.
По статье создалось впечатление, что на роль менеджеров нужно брать хороших тимлидов, буквально переводить инженера в чистые руководители. Тут тоже вопросы, во-первых, на кой чёрт человеку с большим опытом и налаженной работой уходить в управление, менять сферу деятельности? Во-вторых, кто вам сказал, что он будет с этим хорошо справляться?
Для правильного понимания современных подходов к управлению разработкой и управлению вообще нужно в первую очередь избавляться от комплекса «подчинённый-начальник». Так, например, не надо все менеджерские позиции считать «начальственными». Не надо требовать от хорошего администратора навыков разработки. Тимлид, и даже рядовой разработчик, ВСЕГДА должен быть более квалифицированным инженером, чем, к примеру, менеджер проекта, потому что каждый должен быть на своём месте и хорошо делать именно свою работу. (И влияние в компании он тоже может иметь значительно большее.)
Вот метрики, взятые с потолка, или разрыв горизонтальных связей в компании — это просто плохо сделанная управленческая работа. Плохой сотрудник он и в Африке плохой, будь он менеджер или инженер.