Привычка кодить

Прогноз проблем по привычкам программиста

(рубрика - Нюх на баги)

Исходя из многолетнего опыта работы программистом, аналитиком-внедренцем, в тестировании и техподдержке могу заверить вас, что у каждого разработчика есть свой почерк написания кода. И не важно насколько строгие правила кодирования приняты в компании: кто-то играет с порядком параметров, кто-то с наименованиями объектов, кто-то с самописными или стандартными подпрограммами. Одно и тоже действие можно написать, используя стандартные функции (тогда тестировщикам заранее известны слабые места кода), а могут сочинить универсальный или сложно-запутанный код, от которого тестировщикам можно будет ждать всяких непредвиденных ситуаций.
Поэтому, чтоб тестирование не получалось всегда неожиданностью, ниже сопоставлены некоторые человеческие особенности с написанным программистом кодом. А именно, с самым распространённым действием – чаепитие или кофе-брейк. В зависимости от того, как программист готовится или завершает чайно-кофейную церемонию, родились связки с его фирменными ошибками. Когда же сфера IT перешла в удалённый режим, и команды стали распределёнными, естественно пропала возможность наблюдать за общением программиста со "своей кружкой". Но, оказалось, что по скриншоту рабочего стола тоже можно определить тип программиста.
В начале карьеры мои обязанности ограничивались программированием и техподдержкой. В те времена о тестировании вообще никто не говорил и не слышал, потому что сами программисты выполняли аналитику, кодирование, отладку, внедрение и поддержку. Но в силу того, что отпуска в своём большинстве давались полностью (вплоть до 40 рабочих дней), то кому-то приходилось замещать сотрудника в ответственные дни отчётов. В до-САПР-овские времена, когда не было "Галактика" или "Axapta", автоматизация предприятий проводилась собственными силами, а это значит весь код был самописным, без особых корпоративных стандартов. В то время легко было определить почерк кодера: кто-то давал переменным и объектам особенные имена (короткие, нелогичные, без привязки к функционалу), кто-то использовал особые конструкции или ранее-написанные собственные блоки. И если вдруг в отсутствии замещаемого сотрудника падал код, то заместителю поначалу приходилось тратить не мало времени на понимание такого легаси. Вспомните себя студентом, переписывающим пропущенные конспекты лекций от разных однокашников: не с первой страницы начинаешь бегло читать чужой почерк. Также и с легаси-кодом – не с первого блока кода понимаешь логику прописанных команд.
После перехода из универсальных программистов в разряд всемогущих тестировщиков в моём арсенале разнообразия почерков программистов стало больше. При чём сюда добавились и аналитики, и конечные пользователи, присылающие своё видение на проблемы продукта. Высоким словом "разработчик" в некоторых компаниях называют программиста, совмещающего роль с аналитикой. Поэтому, как продумаешь логику, так она и отработает в коде. В моём докладе о лёгкости тестирования кода с помощью утилит аудиторов кода уже говорилось об основных причинах самых заковыристых багов. Они-то и кроются в особенностях почерка кодировщика. А коль скоро характер программиста не перевоспитаешь, то и его фирменные баги вы сможете вылавливать в первую очередь. На счёт скорости обнадёживать вас не буду, но направления для поиска вам будут очевидны.
Итак, типы почерков программистов делю на 6 групп.
Чистюля (аккуратист, педант)
На его рабочем столе никогда не бывает ничего лишнего, весь минимальный набор (клавиатура, мышь, за редкостью чистый лист и карандаш) расставлен "под линеечку", ни пылинки-соринки, ничего мешающего рабочему процессу. Если говорить об иконках на рабочем столе операционной системы компа, то там могут быть лишь стандартные приложения, либо всё необходимое разнесено по папкам. Свою кружку моет сразу после чаепития и убирает на строго отведённое место в закрытом шкафу.
Исходя из описанного поведения, программист-чистюля привык писать код так, чтобы объём и логика кода строго соответствовали описанному заданию, все переменные после использования были очищены. Вроде бы всё должно быть прекрасно, но программист-педант опасен тем, что программа часто недостаточно обрабатывает исключения, не прописанные в ТЗ, либо умышленно опущенные из-за их стандартности, он же привык, что всё разложено по полочкам и ничего лишнего не мешает его взгляду. Перед использованием переменных программист-аккуратист забывает проверить их на корректность объявления и присвоения значений, он же привык, что его кружка всегда чистая. Поэтому код от программиста-чистюли надо проверять исследовательским методом на неописанные в ТЗ ситуации, нагрузочные и интеграционные тесты делать на передаваемые и входящие переменные. В качестве профилактики можно применять правило Code Review, результатом проверки которого является список параметров процедуры, использованных не по назначению.  
Хозяйчик запасливый
Его рабочий стол напоминает склад тысячи мелочей, ящики тумбочки еле закрываются от всего "очень нужного", вполне вероятно он оккупировал и рядом стоящий шкаф под свои полезняшки. Иконок на рабочем столе компьютера видимо-невидимо, разбросаны по всей площади и на первый взгляд в хаотичном порядке. Скорее всего кружку для кофе или чая он держит на своём же рабочем столе, чтоб она всегда была "под контролем", моет её тщательно перед чаепитием. В силу привычек, программист-хозяйчик пишет код "с запасом", программирует неописанное в ТЗ, но на его взгляд возможное при исполнении программы. Код запасливого программиста надо проверять на избыточность объявленных переменных, на достаточность алгоритмов без половинчатого кодирования единичных исключений. Код хозяйственного программиста может быть похож на "лапшу", поэтому в качестве профилактики надо применять оптимизацию блок-схем и сокращать запланированное ему время на написание кода.
Всезнайка
Ученость всезнайки видно по обилию литературы на столе, рабочий стол компьютера – это научный отдел всемирной библиотеки или линки на всевозможные новостные каналы. У него отдельные кружки и стаканы, бокалы для чая, кофе и прочих жидкостей. Их много, и все они разные. Исходя из жизненных пристрастий, код всезнайки заумен, изобилует сторонними библиотеками, возможна перестраховка в виде шифрования. Проверку стоит начинать с поиска "мёртвого" кода. Множество унифицированных вспомогательных функций можно единожды привести в соответствие, но их использование заумным программистом усугубляет интеграционные баги. Обязательной профилактикой для всезнайки служит публичный процесс Code Review, нагрузка по передаче знаний и умений сотрудникам всех отраслей, что позволяет ему понять причины собственных ошибок. Не ограничивайте свои тесты программы от Всезнайки только теорией от гуру, поскольку его сочинение может оказаться слишком навороченным. Пример о граничных значениях: обе функции определяют принадлежность значения к определённому числовому промежутку, но описанный способ матрицы можно применить только к функции "if_cycl" при тестировании "чёрным ящиком".

Рубаха-парень (общительный)
Любитель поболтать вместо кодирования опознаётся по количеству средств связи на рабочем столе. Это могут быть как различные виды телефонов, смартфонов, раций, так и иконки чатов, конференций, аудио-видео коммуникационных каналов. "Свой парень" предпочитает чайно-кофейные кружки из общей кухни, за которыми не надо следить и мыть. У общительного программиста вместо кода на первом месте коммуникации, поэтому программа может быть просто недописана, либо блоки после копи-паста недоправлены. В первую очередь продукт от ультра-разговорчивого программиста надо проверять на точное соответствие ТЗ в области полноты и законченности, каждый из новых пунктов проверять на корректность, не допуская частичной выборки классов эквивалентности. В качестве профилактики по недопущению им багов предлагается не отвлекать его от работы, а общение на нерабочие темы выносить только в перерывы.
Фантазёр жизнелюбивый, живчик
Радость жизни в код не впишешь, и по хаосу на рабочем столе его легко выявить. Среди иконок не мало игр. Кроме компьютера на столе бытовое множество вещей, будто дом или объект его увлечения переехал на работу. Разнообразные чайно-кофейные кружки, в том числе и чужие, можно найти не только на столе, но и в тумбочке, или на чужом столе. Он не замечает даже, когда меняет бокалы, стаканы на общественные или соседские. Это признаки (законы) общежития, и они отражаются в его коде в виде опечаток, обилия неоптимизированного кода, неочищенных переменных и параметров без присвоенных значений. Из-за лёгкого отношения программиста к жизни тестировщику нужно тщательно проводить регрессионные и нагрузочные тесты. Профилактикой может быть работа в паре с Чистюлей или Всезнайкой до момента, когда за него будут выполнять более 30-40% задач.
Пофигист (разгильдяй, тупокодер)
Бардак и грязь на столе, немытые кружки, минимум иконок – признаки тупокодера. Его код не низок, не высок, не узок, не широк, то есть на первый взгляд в точности соответствует ТЗ. Но опасайтесь недописанных блоков, недопроверенных опечаток, неучтённых исключений, незакрытых уязвимостей. Все виды и методы тестирования актуальны для кода от пофигиста. Растормошить его можно доверить любому увлечённому общим делом сотруднику.

Рекомендации по определению типов: смотрите когда и как тщательно программист моет кружку (до или после чае-кофе-пития), сколько их у него и в каком они состоянии, что ещё имеется на рабочем столе, изучите расположение иконок в его операционной системе. Проанализируйте баги и их причины, составьте таблицу в разрезе программистов. Обычное наблюдение даст вам понятие о почерке программиста: сопоставьте типы кодеров и их фирменные баги. Впоследствии можете начинать тестирование с фирменных багов, это ускорит Вашу работу и повысит качество продукта, потому что будете находить проблемы, казалось-бы не очевидные, но вполне вероятные на стороне конечного пользователя.
И ещё несколько подсказок.
Типы могут пересекаться в одном программисте, поэтому подглядывать за поведением кодера стоит регулярно, особенно перед передачей задачи на тестирование.
Не буду скрывать, к некоторым перечисленным типам относится и мой стиль кодирования.
Наиболее действенна профилактика багов, когда в неё вовлечены все сотрудники. Для этого можно на стендапах или ретроспективах выделять время для напоминалок, а сами правила формулировать в стишках, песенках, поговорках или анекдотах. Например, для забывающих очищать переменные упомяните лозунг "Уходя гасите свет" с расшифровкой о нагоревших киловаттах для пустоты. Также действенны публичные Code Review с привлечением тестировщиков в качестве слушателей. Такие собрания полноценно заменяют митинги о передаче знаний.
Надеюсь, у каждого из вас уже есть свой список типов программистов и их фирменных багов. Это хорошее подспорье для увеличения скорости проверки продуктов.

Тестирование = Критика ? (ГКЧП-3)

Статья "Почему разработчики не могут быть хорошими тестировщиками?" (корректная ссылка на использованный оригинал "Why can’t developers be good testers?") и её обсуждения натолкнули на мысль, что роль тестировщика в команде разработки часто путают с понятием о критике.
Ниже приведён перевод статьи "There’s a human on the other side of your code review" (Tadas Antanavicius, Full-Stack Engineer @SolutionLoft), в  которой автор тоже путается в формулировке отчётов о проверке кода.

##############################
Человеческий фактор при проверке кода

Для большинства разработчиков программного обеспечения проверка кода является неотъемлемой частью жизни; но в достаточной ли мере мы разделяем жизнь и код?
“Не углубляйтесь в персональность комментариев, они для инженера всего лишь один из способов донести свою мысль”.
Для меня эта цитата – один из советов начинающим программистам. Я сильно не задумывался над этим, но, по-моему, смысл в словах есть.
Поскольку я сам проверяю код и моя работа ежедневно проверяется, то эти строки опять и опять всплывают в моей памяти. И совет-то весьма прост, чтобы следовать ему. Но, меня волнует – а в чём же статус-кво?
О кодревью было уже много сказано и написано. “Это не только про ошибки, но более об индивидуальном понимании кода”, “мы о минимизации времени на проведение проверок”, “молодые разработчики учатся быстрее, когда их просят делать ревью”, и многое другое. Я хочу исследовать другой аспект анализа кода, который часто игнорируется: чем помогает (или мешает) проверка кода для поднятия духа товарищества, доверия, в обучении и прогрессе?
И с этой мыслью собрал горстку идей, которые мы можем реализовать для укрепления команды и повышения результатов её деятельности.
Поговори со мною, кодер
Повсеместно проверка кода начинается без обсуждения темы программистом и проверяющим. Но даже если задача имеет пояснения высокоуровневой архитектуры, то рецензент понятия не имеет, как и по каким причинам программист уложил полноценно идею в несколько файлов.
Буквально пять минут общения — персонально, по телефону или с помощью тексто-обменника (мессенджер, чат) — дают очевидное преимущество для производительности и качества. Как проверяющий, Вы лучше других оцените сочетаемость структуры файла не только с основными соображениями разработчика, но и с причудами или предположениями, которые он или она включили в код, а также выявите какие-то конкретные проблемные области, требующие Вашего усиленного внимания.
Кроме того, Вы даёте кодеру шанс обучить Вас, ревьювера, чему-то пока Вам неизвестному. Программист уделяет много времени коду, дотошно исследуя проблемные места. Прежде чем вторгаться в идеально созданное королевство кодировщика, чтобы осушить многочисленные болота, дайте ему возможность гордо провести Вас по этому изящному лабиринту.
Автоматизированные приложения разрушают межличностный контакт в зародыше
Дежурное решение для оптимизации проверок - автоматизация. Отладчики, непрерывная интеграция, автоматизированные тесты, метрики покрытия кода   —  несомненно всё это способствует повышению качества кода, уменьшению количества циклов обратной связи и снижению трат времени впустую.
Независимую критику предоставляет автоматизация, и этот факт пока ещё не оценён по достоинству.
Никому не нравится критика, и этот негатив усугубляется при прочтении большинства отчётов проверяющих. Напоминая Вашему коллеге использовать табуляцию вместо пробелов, разрозненный регистр вместо строчного, или реорганизовывать вкрапления файлов, вы не завоюете уважение офиса, даже если это действительно улучшит восстанавливаемость кода в своей основе.
Вы ничего не теряете, когда утилиты говорят за вас, и это не нарушит целостность кода. Поэтому не стесняйтесь расширять список задач для автоматизации, но не переходите грань межличностных отношений со своими товарищами пока не стало слишком поздно.
Отзыв о коде формулируйте кротко и ободряюще
Нет ничего более деморализующего для кодера, чем читать сухой, ничего не значащий комментарий “Этот алгоритм выполняет квадратичную функцию”.
Простой комментарий проверки кода, который сообщает “Сделайте X” или “X является неправильным”, сам по себе часто оказывается некорректным вопреки Вашим ожиданиям. И даже если это не так, и в текущий момент не соответствует вершине Вашего ума, но в конце концов разработчик имеет право заявить, что его решение сделать так, а не иначе – осознано и имеет объективные причины. По истечении дня разработки, даже приученный к Вашему стилю программист, будет раздражаться, если Вы не оцените его усилий, не предложите в обязательном порядке выход из положения, но высокомерно заявите о собственной значительности.
По крайней мере, предваряйте свои комментарии словом «пожалуйста». Формулируйте Ваши комментарии в виде вопроса: “А Вы учли выполнение X способом Y?” А если Ваша догадка по правде говоря субъективна, то найдите случай попросить: “Вы могли бы пояснить вот это мне?”, и скорее всего Вы узнаете что-то, доселе Вам не известное, или по крайней мере дадите разработчику возможность продумать этот момент более тщательно и найти лучшее решение самостоятельно.
Самое главное, Вы не приучите бояться проверок. Они не будут бояться пробовать решать проблему по-новому, потому что они будут счастливы обсудить с Вами применение и отдачу нового подхода. Они будут продолжать задумываться о “наилучшем коде”, а не о “том, что скажет проверяющий”.
Я понимаю, что мы, как инженеры, склонны к краткости и точности. Но сэкономленное на оптимизации время не стоит Ваших добрых отношений с сотрудниками.
Используйте время общения для обучения
Иногда быть скромным и воодушевляющим хорошо, но давайте заглянем на шаг вперед.
Студент находится по ту сторону Вашего анализа. В большинстве своём просто надеется на высоко- классность и одобрение рассматриваемого кода, но, если Вы собираетесь опровергнуть его надежды, то сделайте это с максимальной пользой его/её времени. Обоснуйте своё мнение. Обратитесь к документации, из которой нашли изящный прием, или к блогу, где Вы подчерпнули наиболее успешную практику.
Мало того, что это закрепит некоторые знания Вашего подопечного так, что Вам не придётся вылавливать те же ошибки в следующий раз, но и он/она начнёт уважать Вас больше, поскольку поймёт значимость отдачи каждого анализа кода, проводимого Вами.
Займите сторону наставника вместо остановки ошибок человеческого фактора в выпускаемом коде. И это окажется более полезным для всех вовлечённых в конфликт.
Когда что-то ломается - это только *Ваша* ошибка
Это непременно произойдёт. Вы одобрите анализ, код опубликуют, и … что-то рассыплется. Программист отчаянно будет править и минимизировать влияние пользователя, но ущерб нанесён. Кодер виноват, все в Вашей команде это знают, и это будет внутренним конфликтом до тех пор, пока это не дойдёт до умов всех членов команды.
Иной ход дела, когда вы вступаетесь за разработчика и берёте вину на себя.
Отказывайтесь до последнего от функции орала. У программиста уже достаточно напряга: исправление ошибки идёт под давлением, его имя прописано большими буквами в истории контроля версий рядом с тормозящим комитом, потратив много часов на сочинение кода он не мог предположить наличие этого бага.
И у Вас есть очень маленькая лазейка. Объявите, что это Ваша ошибка, Вы забыли рассмотреть крайний случай, но этого не случится в следующий раз. Посидите с программистом, чтобы исправить ошибку. В худшем случае Ваша команда придет к заключению, что это была ошибка вас обоих и оставит вас в покое. Но независимо от их мнения, Вы построите длительное взаимопонимание с разработчиком, которого Вы поддержали, и заслужите уважение босса, который пристально наблюдал за развитием ситуации.

Анализ кода не должен быть просто процессом, пунктиком для проставления галочки. Когда в деле учитывается человек, то путь, которым Вы достигли результат, имеет более высокое значение, нежели сам результат.
##############################

Надеюсь, должностные инструкции в Вашей компании однозначно отвечают на вопрос об "идентичности" тестирования и критики.
Критика базируется на трёх китах - похвали, поругай, предложи. Тестировщик оперирует фактами об актуальном состоянии программы, знает из ТЗ (техническое задание, описание фичи заказчиком) каким должен быть ожидаемый результат после определённых шагов, умеет (а в некоторых компаниях обязан) определить причины выявленной проблемы и пути её решения. Программист считает ошибку наполовину исправленной, если в описании указаны причины, а планировщик задач не поднимает BV (business value) багам без явных причин, чтоб не тратить время кодера на их поиск. Да, баг с расписанным ходом решения правится быстрее, но ведь это за счёт квалифицированности проверяющего, а не исправляющего.
Результат работы проверяющего - отчёт о состоянии программы - не входит в цикл художественных произведений, поэтому должен быть на техническом языке. В компании с выделенным отделом тестирования программист не ждёт вступительных слов "красивый код, но, пожалуйста, исправьте ..." в формулировке бага. Формулы Халстеда о наличии багов в любом коде определяют основную обязанность тестировщика, и об этом стоит помнить кодеру. А постоянная якобы дипломатичность в виде просьб о разъяснении достаточно быстро и надолго опускает эксперта до позиции "мальчика для битья". После одного признания вины за баг руководство и вся команда привыкает иметь всегда под рукой единственного грешника. Тем самым из высоко-квалифицированного специалиста тестировщик превращается в "мусорное ведро" - отдачи не ждут, но нечистоты есть куда поместить.
Тестировщик - такой же полноценный член команды, как и любой разработчик. Он - неотъемлемое звено в производственной цепочке, поэтому не стоит всю вину за провал скидывать на того, кто способствует улучшению продукта. Рядовой QC (quality checker) вырастает в эксперта по тестированию и самостоятельно обучаясь, но, изначально утерянное уважение к рангу проверяющих, команда не способна воспринимать должность тестировщика любого уровня как ровню разработчикам. Вероятно поэтому в Facebook и Microsoft тестировщиков нет, но есть инженеры по тестированию. Ценность профессии подтверждена.

Ссылки по теме:
Я бы в тестеры пошёл...
Качество и уважение
Командность
Им о нас
Каество кода одним числом

Дорогие trivial-ы

В распределённой команде руководитель время от времени поставляет тривиальные баги команде тестировщиков. Но самому их вносить в систему учёта багов ему лень. А поскольку команда общается посредством Slack, то картинки постятся в чат, часто без пояснений о конкретном месте проблемы, мол: "Ищите сами, всё же видно!" Ещё ситуацию усугубляет серверная версия Jira без выхода в Инет. Билд с фиксом шеф обычно желает получить мгновенно, так как считает такие баги "пятиминутками". Но в 5 минут никогда невозможно уложиться.

Устные просьбы оформлять сразу в Jira опубликованные в чате картинки успеха не имели, поэтому пришлось подсчитать убытки всей команды из-за лени начальника.

Bug Reporter	Tester	Bug Fixer
3-5 мин на снятие screen shot, редактирование и вставку в Slack	1-3 мин на чтение чата и понимание проблемы (где происходит, как получить, в чём собственно проблема)	1-3 мин на чтение и понимание проблемы (где происходит, как править)
10-30 мин на собственное возвращение к прерванной работе	10 мин – 2 часа на воспроизведение в разрабатываемом билде и опубликованном	5 мин правка и submit в систему контроля версий
	опционально: 30 мин на выяснение подробностей с репортером	10 мин – 2 ч проверка в скомпиллированном приложении
	10 мин на пересылку оригинала screen shot из Slack в локальную сеть с Jira	10-30 мин на собственное возвращение к прерванной работе
	3-10 мин оформление задачи в Jira
	10-30 мин на собственное возвращение к прерванной работе
	10 мин – 2 ч проверка после правки
	опционально: 20 мин оформление возврата, разночтений и последствий недоправок, недопроверок
13-35 мин	44 мин – 5 ч 43 мин	26 мин – 2 ч 38 мин

Итого, на одну "пятиминутку" требуется от 1 ч 23 мин до 6 ч 56 мин общекомандного времени.
Сократить перерасход времени можно за счёт регулярной проверки новооформленных задач одним или несколькими сотрудниками QA. При этом нет необходимости отрываться от текущих дел, так как на new-task-review обычно уходит 10-20 минут ежедневно в рамках регулярных запланированных работ, а правка и проверка задач тоже в планах всей команды и нет необходимости отрывать кого-то от текущих дел.

Bug Reporter	Tester	Bug Fixer
3-5 мин на снятие screen shot, оформление и вставку в Jira	1-3 мин на чтение и понимание проблемы в рамках проверки задач Jira	1-3 мин на чтение и понимание проблемы (где происходит, как править)
10-30 мин на собственное возвращение к прерванной работе	10 мин – 2 ч проверка после правки	опционально: 30 мин на выяснение подробностей с репортером
	опционально: 20 мин оформление возврата, разночтений и последствий недоправок, недопроверок	5 мин правка и submit в систему контроля версий
		10 мин – 2 ч проверка в скомпиллированном приложении
13-35 мин	11 мин – 2 ч 23 мин	16 мин – 2 ч 38 мин

При таком раскладе затрачивается от 40 мин до 5 ч 36 мин общекомандного времени на "пятиминутку". Экономия – от 43 мин до 1 ч 20 мин.

Молчание шефа

Можно ли руководить людьми, не общаясь с ними? Нет.
Говорят, что шеф – это особый характер. Есть ли тип характера, с которым не бывает начальника? Нет, значит любой может им быть.
Даже если весь обмен информацией проходит не вербально, то у любая сторона диалога имеет право высказать всё или умолчать о каких-то деталях. Именно об умалчиваниях и пойдёт речь.
С какой целью шеф отмалчивается по некоторым темам? Главная задача начальника – аккумулировать и распространять информацию – может служить как на благо, так и для гибели коллектива. Как распознать шефа, скрывающего инфу? Какие результаты могут быть от недосказанности?
Болтун-молчун
Болтун высокопарными эпитетами может заменить материальную оценку труда подчинённых. Молчун, не высказав руководству и сотрудникам свои претензии недоделок или иных промахов подчинённых, огораживает их от штрафов.
Болтун, превозносящий фактический уровень одного сотрудника пред остальными, завышает уровень самооценки одного работника и снижает уважение всего коллектива как к этому сотруднику, так и к самому шефу за очевидную ложь.
Молчун, вовремя не поднявший вопрос о бездействии, лени, некомпетентности одного сотрудника, в итоге может уволить хорошего работника себе же в ущерб, не разобравшись в сути проблемы.   
Утопист-прагматик
Фантазируя о высотах продукта, шеф может увлечь команду энтузиазмом. Утопист, возлагающий надежды на кандидата с красивым резюме, не сумевший вовремя выяснить профессиональный уровень, распределяет задачи без оценки риска проекта.
Прагматик строит планы по фактическим данным. У начальника, обуздывающего рвение трудоголиков, вполне возможно есть цель уволить за неисполнение должностных обязанностей.
Интеллектуал-недалёкий
Демонстрирование своего интеллекта, не соизмеренного с уровнем подготовленности команды, приводит к недопониманию и появлению "серого кардинала" в рядах подчинённых.
Передача знаний – один из основных пунктов должности руководителя. Отсутствие обмена опытом и профессиональной информацией превращает команду в сборище незаслуженно получающих деньги.
Экстраверт-интроверт
Ожидаемо выдвигать экстраверта на роль лидера, но гипер-общительному шефу сложно соблюдать субординацию. У открытого к общению руководителя можно даже на корпоративе узнать планы проекта.
Распознать настроение интроверта – сложная задача для сотрудника, просящего о повышении зарплаты или ранга. Зачастую секретность или недалёкость некоторых вопросов прикрывается замкнутостью.
Красноречие-косноязычие
Хороший словарный запас – ключ к успеху оратора. В обязанности скрам-мастера входит проведение митингов, но если существует лингвистический барьер, то совещания могут затягиваться или быть абсолютно непродуктивными. Когда конкретные идеи обличаются лишь в намёки, то консенсунс спора не достижим. Ясное и чёткое изложение способствует прозрачности всего процесса производства – от планов до отзывов клиентов. Недосказанность – только повод приобрести телепатические способности, но косноязычие не научит собеседников чтению мыслей. Перебарщивание с болтовнёй на отвлечённые темы роняет авторитет, так как отвлекает от главной идеи диалога. Излишнее красноречие может завуалировать мысль до степени извращённого понимания.

Во времена советской власти руководителей обучали профсоюзы и парторганизации, давали точно понять о чём обязательно надо говорить с подчинёнными, а о чём умалчивать. В обучении или повышении квалификации начальнику давались основы правил общения, воспитания духа командности, как быть эффективным арбитром конфликтов. Выпускники таких курсов, к слову сказать – бесплатных, могли с пользой применять элементы диктаторства и демократии, знали законодательство, гарантирующее ответы на обращения подчинённых (в настоящее время Федеральный Закон №59) и запрет на размежевание команды на почве дискриминации (Статья 3 Трудового Кодекса).
Хорошо обученный руководитель не даёт пустых обещаний на собеседовании, не игнорирует идеи младших по рангу, свободно берёт на себя ответственность за слова свои и подчинённых.
Относитесь с осторожностью к словам "требуется работник с чувством юмора", потому что за ними могут прятаться бесчисленные гнобления, пристрастие к промахам и равнодушие к успехам.
Отмалчивающийся шеф опасен непредсказуемостью: собственные незнание дела и отсутствие информации прикроет некой секретностью бизнеса, усердие и энтузиазм сотрудников воспримет как оппозицию, сочинит отговорки про технические проблемы при невыплате долга, за счёт клеветы и фальсификата уволит "неудобного", а потом запретит с ним общение для предотвращения раскрытия тайны изгнания.
Задумайтесь над профессионализмом босса: общение с ним вызывает у Вас страх или успокоение, неприязнь или уважение, повышается или нет Ваша трудоспособность после разговора с шефом?

В фильме "Сатисфакция" Евгений Гришковец сказал, что страх – это честность, а уважение – это порядочность. Любой начальник – такой же человек, как и все мы, значит может заслужить уважение, не требуя беспрекословного подчинения.

Командность

Хотелось бы маркером пройтись по нижеследующим словам в статье "Давайте жить дружно: как сложные коммуникации на проекте сделать приятными":

• достижение сплоченности как важного фактора эффективности
• учет мотивации каждого конкретного сотрудника в зависимости от его выявленных целей и желаний
• излишнее неформальное общение
• неумение аргументировать
• нежелание и неумение слушать
• старайтесь задавать максимально простые и понятные вопросы
• уточняйте, почему этот вопрос важно решить именно сейчас, а также какие сроки поставлены
• неформальное общение часто перетекает в наглое перекидывание задач
• Сведите неформальные беседы на рабочем месте до приемлемого минимума: на перерывах, после работы, на коротких 5-минутных паузах на чаепитие
• рассматривая вопрос с разных сторон, можно выявить слабые стороны продукта

А ещё "на полях" дописать:

• В любом диалоге надо уметь не только слушать, но и услышать мысль собеседника.
• Поговорка "не спать на работе" имеет много смыслов - помните о всех.
• Следуйте правилу "личное не для работы", тогда легче будет избежать обилия неформального общения, перестанете выплёскивать болезненный негатив на сотрудников, все официальные приказы будете читать как просьбы.
• Подсказка скромным - перед всеми вопросами проговаривайте фразу "Боюсь спросить". Тогда сразу сможете включить всех, откликнувшихся положительно, вписать в список своих единомышленников. 
• Люди способны сотрудничать лишь в двух случаях: когда все доверяют всем, или когда никто не доверяет никому. Если перепутать, получится бардак.

Жёсткая правда

Да, тяжко признавать свои ошибки, но перед жёсткой правдой любой лентяй и лгун бессилен.