7 признаков говноменеджера

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

Офисный планктон пытается разобраться в сортах такого же планктона.

Смешно.

Ну и баян.
Прямо аккордеон.

Тут клуб любителей бородатых статей?

Это все от незнания реалий

Не уверен. Скорее от обиды на то, что реалии-таки могут сильно отличаться от нашего представления о них
Продолжаю список
Кстати, прям можно так и назвать. В каких ситуациях без говноменеджера не обойтись?
4. Непримиримые конфликты между крутыми говнокодерами
Тут без говноменеджера (или миниговноменеджера или корпоративного паразита) никак не обойтись. Иначе измерения у кого и что длиннее проект полностью останавливает
5. Работа на рынок
На рынок обычно выпускают неработающие продукты. И это правильно. И не потому, что с рынка приходят денежки на развитие (не только поэтому), а потому, что на точке старта слабо понятно, а вобще оно кому-то нужно? и если нужно, то кому? (целевая аудитория), и что конкретно этому «кому» нужно. за что он готов платить, а за что нет.
Нормальные менеджеры (которые думают, что они самые умные и гениальные) тут же начнут про качество говорить, мол не купят падающее барахло. А говноменеджерам — пофиг. если не купят, значит не нужно никому, если очень нужно, то и барахло купят, а если не нужно — занафига качество?
Качество начинает играть ключевую роль, когда не очень нужно.
6. Наличие в команде люмпенов

Думаете люмпенов тоже говноменеджеры взращивают? неа

Как по мне много фикалий и слишком однобоко. Просто выпячивается нериализованный юношеский максимализм. Абсолютно не учитываются задачи и время жизни проекта. Это все от незнания реалий:
1. Работа на выброс.
Вот например высокое руководство отмывает бабло и подписывает контракт на функционал только для прикрытия и как оно будет реализовано их вообще не интересует, а команда будет в шоке — инициативы не принимаются, архитектура не продумывается, тесты не делаются, а сказали только одно — у вас месяц! Моя команда за последний год сколько функционала написала «на выброс», что жуть просто, а старались, продумывали — только сами, не понимая, что это всего-лишь галочка в контракте, который должен быть сдан тогда-то и тогда-то.
2. Одноразовые работы.
Некоторые тулзы вообще разовые, они просто должны один раз отработать и нет смысла вообще париться как их будут писать, на входе 2 и 2, на выходе 4, все.
3. Долгожители.
Есть долгоживущие проекты, требование к которым меняется заказчиком по ходу жизни. Вот тут да, надо делать по уму. Тут говноменджером быть нельзя иначе сам же выроешь себе яму и провалишься в нее на поддержке продукта.

В общем много проблем из-за непонимания между руководством и исполнителями, т.к. первые очень любят недоговаривать. Я не включаю сюда личных «плохих» характеристик таких как: самолюбие, звездной болезни, властолюбия, неумения принимать чужое мнение и т.д. Это отдельная тема по психологии.

Да здравствует новая раса говночеловеков, производящих говнокод на говноработе под руководством говноменеджеров за говнозарплату и срущих в каментах на говнофорумах!

по заказу говнозаказчиков и за деньги говнособственников
Картинка, однако. Так наверное думал бог, когда адам вкусил запретный плод и был выдворен на грешную землю
Глядя сверху, как плодятся новые грешники наверное в такой же хлесткой форме формулировал 7 признаков говночеловеков.
Переделать он их не мог — решил «уволиться»

Вот оно оказывается как было: D

Вот вот... И что же делать тому суперкодеру, который оказался вместе с ^%& * (#* на работе? Увольняться или может всех других привести в чувство, хотя, «чувства» у всех разные.

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

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

Похоже что так и есть.

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

Причём тут эпилог? Мне просто интересно почему другие считают что статья рулез и пришла она мне в trending topics on developers.org.ua.

А психологический аспект здесь есть только один — кто работает с $%^*& @ ( — тот или сам такой или скоро им станет.

Вот вот... И что же делать тому суперкодеру, который оказался вместе с ^%& * (#* на работе? Увольняться или может всех других привести в чувство, хотя, «чувства» у всех разные.

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

А психологический аспект здесь есть только один — кто работает с м*даками — тот или сам такой или скоро им станет. Ну то, что успех дела, который напрямую зависит от этих раскладов, может пострадать — эт наверное надо описывать в другой статье. Хотя, как показывает практика — не факт, что все ее дочитают или поймут...

Презентация Асхата:
agilebasecamp.org/...prise-maturity
А про эволюцию компании читать тута:

kniga.biz.ua/...gement/-1/1041

-

-

На конференции по Agile Асхат Уразбаев рассказывал про эволюцию компании. Достатоно четко рассказал почему в компании работают говнопрограммисты, говноменеджеры и выше по иерархии. В общем закономерно, если компания нанимает плохих программистов — значит компания плохая. Все просто! =)

Вообще говоря похоже что некоторые (aka Rus И ему подобные) не совсем догнали или дочитали то, что мне было не понятно, а именно: в чём резонанс статьи и почему она нравится вышеперечисленным человекам.
От себя хочу добавить:
Психологический Аспект:
автор статьи либо
а) считает себя суперкодером (и мало вникал в список основных задач менеджера). Мне кажется оценка действий «плохого» менеджера в статье приведена с позиции программиста.
б) сам является «говноменеджером». Однако эта статья вроде как и написана для обнаружения «говноменеджеров».
в) является непосредственным представителем антиговноменеджера, т.е., как описано тут, скорее тим лидера. Наврядли, иначе откуда столько негатива? Друг его говноменеджер?

Внимание вопрос: кто себя считает «говнокодером» и почему? Как материал для ответной статьи был бы неплох.

Кратко суть статьи для тех кто не догнал или не дочитал (for ex. objective и ему подобные):
1. Философский аспект — во Вселенной ничего просто так не возникает и никуда просто так не исчезает, т.е. если есть в IT Г-кодеры, то есть и Г-манагеры способствовавшие их созданию
2. Социальный аспект — притяжение и круговорот Г. в IT — каждый Г-манагер заслужил иметь в своем распоряжении Г-кодеров и соответственно имеет право обратное утверждение. И будут они крутиться в этой связке пока один их них не захочет измениться
3. Практический аспект — успешные команды не имеют в своем штате не первых и не вторых, т.е. избегайте м*удаков, а если таковые и есть — перевоспитывайте, путем расширения их узколобкового взгляда на отношения, профессию и жизнь, чем собственно и должны постоянно заниматься уважающие себя человеки.

В статье ничего нового — только вновь хорошо пересказанное старое и доброе;)

Мы с вами, «Камрад» на ты не переходили.

Окей, статья жизненная. Очень помогает всем.

Камрад, ты отлично обосновал свою точку зрения — лично тебе не понятно.
Не понятно — подумай.
Подумал — непонятно, но интересно — спроси.

Хотя из написанного тобой складывается ощущение, что ты пост недочитал или читал по диагонали. Потому что ответ на вопрос «почему ответ именно такой» в посте дается. Еще там написано, почему ответ именно такой — ты прочитай, прежде чем комменты строчить.

Да, похоже на крик «суперпрограммиста», который хочет завоевать вселенную своим суперкодом.
Возмущение уж точно ни к чему не прийдёт. Если автор (статьи) сам не в состоянии убедить своего менеджера (например о введении более новой технологии), и при этом, получив негативный ответ, не в состоянии понять почему ответ именно такой, то сложно назвать этот «крик души» дельным советом.
Хотя возможно просто компания плохая попалась. Во всяком случае мне приходилось слушать такие отзывы.

Я лично не могу понять в чём «резонанс» статьи.

to Александр Маненко

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

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

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

to Александр Маненко

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

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

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

Говорите неправильно юзать БД в тестах и тест который юзает БД не юнит тест?

Та же фигня, когда человек понимает, что использовать реальные файлы, соединения с удалёнными машинами и т.п. в тестах неверно, но «так проще, нафига писать стабы». А то, что иногда тест валится, из-за того, что файл понадобился антивирусу или еще какой нечисти, удаление не получается — «ну так ачтоподелать, перезапусти, может попустит».

© «Узнаю брата колю»
При этом что самое прикольное — перед такой бодягой ты, будучи руководителем обучения, спрашиваешь -, а не хотите ли тренинг про то, как делаются эти самые тесты? Тебе отвечают — да ну нафиг, мы и сами все знаем!

А потом на сессии аджайл сообщества чудо-писатели тебе сообщают — пробовали мы писать юнит тесты, они неэффективны и тормозят разработку!

Юнит тестирование? Нууу это вобще в наших краях нечто: -)
Признаюсь честно я ни разу не видел проекта (конечно слышал о многих) где в лучших традициях TDD сначала писались тесты, а потом код который эти тесты должны тестить и походы еще активное юзались всякие IoCи, моки и прочее.
То что я видел это была какая-то куча кода (иногда очень даже не плохо продуманная архитектурная), доведенная до какого-то приемлемого состояния, а потом уже на все это писались Юнит-тесты. На вопрос зачем оно нам надо отвечалось что у нас много багов и это все нам очень поможет. Когда указывалось что основное правило TDD это писать тесты и думать о коде отвечалось что тогда некогда было об этом думать, а вот сейчас заказчик решил что неплохо было бы и юнит тесты накатать. На замечания что для того чтоб написать какие-то вменяемые тесты необходимо рефакторить всю систему смотрели как на идиота, делали круглые глаза и спрашивали зачем?
В итоге тесты писались... Классные тесты получались...

Вершиной подобного творчества были тесты бизнес-логики которые лезли в реальную БД (в которой тоже лежали только такие данные при которых тесты должны были пройти), доставали оттуда данные и сравнивали с шаблоными. Говорите неправильно юзать БД в тестах и тест который юзает БД не юнит тест? Ну, а для того чтоб заменить их теми же моками надо было рефакторить БЛ и ДАЛ, что могло повлечь за собой лишний геморой и было неприемлемо. Ну, а потом с теми тестами поносились месяц другой да и выкинули на помойку так как пользы от них было меньше чем геморроя.

Ты знаешь — да, именно так.
Это часть, которую я как-то упустил из виду.
Да, действительно, кричать «а у нас и так все хорошо! » — это любимое развлечение.
Написать спецификацию? Зачем, кому она нужна? А у нас и так все хорошо!
Юнит тестирование? Это увеличит время на разработку! А у нас и так все хорошо!
Ну и далее ответ на любое предложение.

Ой, все принакрылось тазом! Странно — ведь было все хорошо? Ну, это звезды так сложились — случайность короче.

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

Так что хотел бы еще уточнить что одним из признаков говноменеджера есть постоянные его заявления о небывалом качестве «надубасенного»: -)

To: Rus
Феерично!

Особенно приятно, что обошлись без политкорректности.

Thanks for hint. Название они перевели как «М*ДАКАМ ВХОД ВОСПРЕЩЕН»

To: Rus
Привет.
Книгу только одну упоминал, No Assholes! Rule, боб саттон написал.
Есть даже русский вариант, если я не ошибаюсь.

Вот только как они перевели название — я даже не представляю:)

2Denis: Sorry за офтоп, Вы в своем блоге упомянули за-голову-хватательную-прыгательную-по-комнате-фейсом-об-тэйбл книжецу про ведение бизнеса, которая содержала адекватную названию/теме инфу — не подскажете название/автора? Хочеться тоже попрыгать;)

Статья получила неожиданно широкий резонанс:)
То: Сергей Остапенко
Нет, как раз напрямую с владельцами я и работаю — собственно у него в подчинении.
Поэтому и пишу — не все меряется чисто на деньги.
Должен быть баланс — оценивать только по деньгам это однобоко: с точки зреня денег можно продать всю команду хэдхантерам и в этом месяце прибыльность будет офигенная. А в следующем?

Я как раз пытался сказать, что надо соотносить «сейчас \ потом».

Да здравствует новая раса говночеловеков, производящих говнокод на говноработе под руководством говноменеджеров за говнозарплату и срущих в каментах на говнофорумах!

Думающий чел — согласен с ним на все 100. Борьба с энтропией в IT это одна из основных задач;)

:) неужели такие менеджеры бывают...,

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