Привет, Хабр!
Сегодня о тимлидском-наболевшем. Вот представьте, образовалась перед вами дилемма: есть в команде специалист, который по человеческим качествам — просто душка, но скорость и качество его работы вызывают желание спрятаться под стол и тихонько поплакать. Как быть? Открыть курсы медитации для успокоения нервов или все-таки признать, что бизнес — это не благотворительный фонд? Предлагаю обсудить. И, чтобы было по-честному, взглянем на ситуацию с двух сторон: со стороны тимлида, который вроде как не очень хочет быть гадом распоследним и обижать хорошего человека, и со стороны разработчика, который, мягко скажем, звезд с неба не хватает. Постараемся использовать здравый смысл и не забыть о человечности.
Начнем с горькой правды. Бизнес есть бизнес, а не GitHub-репозиторий с открытым кодом (удивительно, да?). Так что придется признать очевидное: как бы ни было важно создавать дружелюбную атмосферу в команде, не стоит забывать о главной цели любого IT-бизнеса — пилить фичи, релизить продукты и, в конце концов, зарабатывать деньги! Конечно, позитивная атмосфера в коллективе важна, но еще есть такие штуки, как KPI и ROI.
Робин Гуд наоборот
Представьте, что вы — суперпонимающий, эмпатичный тимлид. У вас возникает соблазн оставить этого неэффективного разработчика просто потому, что он хороший человек. Но вот в чем загвоздка: по сути, вы будете платить ему из денег, заработанных его коллегами, теми, кто действительно выкладывается, фигачит овертаймы и вносит свой вклад в успех проекта. Такой вот странный сценарий Робина Гуда, только он отбирает у работящих, чтобы отдать... ну, не очень работящим.
Давайте начистоту: поделились бы вы своими кровно заработанными? Как бы вы себя чувствовали, если бы часть вашей заслуженной премии пошла на покрытие работы того, кто не оправдывает ожиданий? Вряд ли вы бы оценили такой подход по достоинству.
Рефакторинг или исключение?
Прежде чем принимать радикальные решения, важно пригласить разработчика на откровенный разговор. Обсудите причины его неэффективности и попытайтесь найти пути решения проблемы вместе. Возможно, ему требуется дополнительное обучение, более четкие задачи или просто поддержка и мотивация. Открытый диалог и готовность помочь могут стать ключом к повышению эффективности и сохранению ценного члена команды.
Если же это не помогло, вариантов два:
Рефакторинг. Скорректировать зарплату разработчика в соответствии с его реальным вкладом. Это может показаться жестким, но это способ сохранить справедливость и обеспечить всем соответствующее вознаграждение.
Исключение. Оно же — увольнение. Возможно, это наилучший выход как для компании, так и для самого сотрудника. Он сможет найти работу, которая лучше соответствует его навыкам, а команда — повысить свою эффективность.
Впрочем, бывают и ситуации, когда такой неэффективный сотрудник может оказаться "душой команды" – тем, кто создает позитивную атмосферу, поддерживает коллег, помогает разрешать конфликты и просто поднимает всем настроение. В таких случаях его вклад выходит за рамки выполнения задач и оказывает положительное влияние на общий психологический климат и продуктивность. Его увольнение может негативно сказаться на мотивации и сплоченности команды, поэтому важно взвесить все "за" и "против" перед принятием решения.
Вывод: найдите баланс между эмпатией и реальностью. Удерживать человека на позиции, где он не может реализовать свой потенциал, — это медвежья услуга. Важно быть человечным, но бизнес-решения (и решения тимлида) в конечном итоге должны основываться на том, что лучше для компании и ее сотрудников в целом. Если разработчик не справляется, помогите ему найти свой путь, даже если он лежит за пределами вашей компании.
Отладка карьеры
А что делать, если вы и есть тот самый неэффективный разработчик? Что если это ваш код больше похож на абстрактное искусство, а дедлайны вызывают панические атаки? Не спешите удалять свой профиль на GitHub, давайте сначала попробуем во всем разобраться.
Баг в системе: поиск причин
Признание – первый шаг к исцелению (или хотя бы к пониманию).
Первым делом нужно найти корень зла, то есть причину неэффективности. Может, вы – fullstack-разработчик, но ваш stack переполнен прокрастинацией? Тогда придется включить самоконтроль и научиться тщательно распределять время для работы и для отдыха. А как у вас дела с синтаксисом? Может, опечатки в вашем коде плодятся с такой скоростью, что позавидуют тараканы на кухне? В этом случае стоит подружиться с линтерами и статическими анализаторами. Или, допустим, вы любите все усложнять? Сбавляйте обороты, простота — залог успеха. Используйте проверенные решения и пишите понятный код, который не вызовет у коллег нервный тик.
Патчим карьеру: от багов к фичам
Разговор с тимлидом — не допрос с пристрастием, а возможность получить обратную связь.
Так вот, сначала обдумайте сами, обо что вы постоянно спотыкаетесь, а потом открыто и честно поговорите с вашим руководителем. Это вообще не страшно, тимлид — ваш союзник. Расскажите о своих трудностях, будь то прокрастинация, запутанный код или сложности с пониманием задач. Вместе вы сможете найти решение: возможно, вам нужен ментор, который поделится опытом и поможет разобраться в тонкостях разработки. А может, вам не хватает знаний в определенной области и стоит пройти дополнительное обучение или онлайн-курс. Иногда достаточно просто получить более четкие инструкции и задачи, чтобы начать двигаться к цели.
Но не ждите, что тимлид будет водить вас за ручку и решать все проблемы. Проявите инициативу. Изучайте новые технологии, участвуйте в опенсорс-проектах, посещайте митапы и конференции, общайтесь с коллегами, расширяйте свой кругозор. Покажите, что вы готовы вкладываться в свое развитие.
И, конечно, учитесь принимать критику. Воспринимайте ее не как личное оскорбление, а как возможность для роста. Внимательно выслушайте замечания тимлида и коллег, проанализируйте свои ошибки и сделайте выводы. Даже самые опытные разработчики не застрахованы от промахов, главное — уметь их исправлять и учиться на своих ошибках. И перестаньте уже бояться code review. Вас там не съедят, это лишь возможность пообщаться с коллегами и обменяться опытом.
К вышеперечисленному, пожалуй, еще стоит добавить пару моментов: документация и тесты.
Первое — это (без шуток) спасение для будущих поколений (и для вас самих через месяц). Пишите понятные комментарии, описывайте архитектуру и логику кода, чтобы потом не тратить часы на расшифровку собственных иероглифов.
Второе — это то, что поможет избежать факапов. Пишите unit-тесты, интеграционные тесты, E2E-тесты — в общем, тестируйте все, что можно протестировать, чтобы быть уверенным в качестве своего кода.
Ну и, конечно, экспериментируйте. Пробуйте новые языки, фреймворки, инструменты. Кто знает, может, вы откроете для себя новую страсть или найдете более эффективный способ решения задач.
А если все вышеперечисленное не помогло… Что ж, задумайтесь: может, вы просто не на своем месте? Возможно, стоит сменить специализацию и найти другой путь в мире разработки (или где-то еще)?
Итак, мы провели сеанс психотерапии на тему "Неэффективный разработчик", посмеялись, поплакали и, надеюсь, сделали для себя полезные выводы. Бизнес есть бизнес, а KPI и дедлайны — не пустые слова. Но даже тут есть место для человечности и взаимопонимания.
Ну а чтобы сбить градус драматизма, предлагаю пройти шуточный тест и узнать, какой вы единорог разработчик.
Тест: «Мастер прокрастинации или повелитель багов?»
Этот тест поможет определить, кто вы в мире разработки: мастер прокрастинации и чемпион по написанию запутанного кода, или же вы все-таки иногда работаете. Отвечайте честно, ведь только так вы сможете узнать всю правду о своих навыках (или их отсутствии).
1. Какой из этих языков программирования вы считаете самым сложным?
a) Brainfuck (да, это настоящий язык!)
b) Ассемблер
c) JavaScript (шутка, ха-ха)
d) Язык моего коллеги, который пишет код, понятный только ему
2. Что вы делаете, когда сталкиваетесь с багом?
a) Гуглю ошибку, копирую первый ответ со StackOverflow и молюсь, чтобы сработало
b) Плачу
c) Обвиняю во всем библиотеки или фреймворки
d) Убеждаю себя, что это фича, а не баг
3. Как выглядит ваш рабочий стол?
a) Чистый и организованный (ну-ну…)
b) Как будто по нему прошелся ураган
c) Завален пустыми чашками из-под кофе и банками от энергетиков
d) Там живет семья пауков, и я уже дал(-а) им имена
4. Что вы делаете в первую очередь, когда приходите на работу?
a) Проверяю почту и мессенджеры
b) Открываю соцсети
c) Иду за кофе (и, возможно, не возвращаюсь)
d) Пытаюсь вспомнить, какой сегодня день недели
5. Сколько вкладок открыто в вашем браузере прямо сейчас?
a) Меньше 10 (вы точно разработчик?)
b) От 10 до 50
c) Больше 50, но меньше 100
d) Браузер уже кричит о помощи, а я открываю всё новые вкладки
6. Как вы называете свои переменные?
a) Четко и понятно, с использованием осмысленных имен
b) a, b, c, d… (иногда забываю, что значит "a")
c) Использую имена своих бывших
d) Даю им смешные названия, чтобы хоть как-то себя развлечь
7. Что вы делаете, когда дедлайн уже горит?
a) Спокойно заканчиваю работу, ведь я всё спланировал(-а) заранее
b) Впадаю в панику и пишу код с бешеной скоростью
c) Прошу о помощи коллег
d) Начинаю искать новую работу
8. Как вы относитесь к тестированию?
a) Это важная часть процесса разработки
b) Тестирование? Не, не слышал(-а)
c) Пусть тестировщики этим занимаются
d) Надеюсь, что код заработает сам собой
9. Как часто вы делаете коммиты?
a) Регулярно, с подробным описанием изменений
b) Когда уже совсем стыдно за количество несохраненного кода
c) Раз в месяц, и то, если вспомню
d) Что такое коммиты?
10. Какая ваша любимая функция в IDE?
a) Автодополнение
b) Отладчик
c) «Найти и заменить»
d) «Копировать» и «Вставить»
Больше ответов «a»: Разработчик-единорог
Вы существуете? Серьёзно? Чистый код, организованный рабочий стол и планирование — всё это про вас. Возможно, вы тайный агент из будущего, посланный, чтобы показать нам, как надо работать. Или вы просто очень хорошо умеете притворяться.
Больше ответов «b»: Кодоборец
Вы — представитель самого распространенного вида разработчиков. Вы умеете писать код, иногда даже хороший, но не без помощи Stack Overflow и кофеина. Дедлайны — ваш вечный враг, а рабочий стол — поле битвы между порядком и хаосом. Но главное — вы не сдаетесь и продолжаете совершенствоваться (когда есть время).
Больше ответов «c»: Инженер Хаоса
Ваш девиз: «Работает? Не трогай!». Дедлайны? Пффф. Тестирование? А зачем? Вы пишете код в состоянии потока (или паники), питаетесь энергетиками и свято верите, что все баги — это фичи. Ваш рабочий стол — портал в другое измерение, а в коде черт ногу сломит. Но, как ни странно, всё как-то работает.
Больше ответов «d»: Квантовый программист
Кто вы? Откуда? И как вы вообще сюда попали? Возможно, вы — гений, который видит мир кода иначе, чем все остальные. А может, вы просто заблудились и случайно оказались за компьютером. В любом случае, ваш подход к разработке — загадка, окутанная тайной.
Независимо от результата, помните: главное — получать удовольствие от своей работы (или хотя бы от процесса её откладывания). А совершенству, как известно, нет предела!
UPD: исправлена ошибка с тестом
Комментарии (28)
orki
16.04.2024 09:23Удерживать человека на позиции, где он не может реализовать свой потенциал, — это медвежья услуга.
То есть не вы увольняете, а перестаете удерживать потенциал человека, отпускаете на волю!
Тут нужна картинка с пингвином.
alysnix
16.04.2024 09:23не раскрыто понятие "хорошего парня". вообще-то существуют манипулятивные методики и люди, для которых быть "хорошим парнем" - это способ существования и добычи пропитания.
nickolaym
16.04.2024 09:23+6Кто вы, мастер упёртости или пофигист? Отвечайте честно.
Кликать на КАЖДУЮ засеренную строчку опросника - мотивирует вас, "вы узнаете что-то новое" или заставляет думать о личности автора?
Saveliy Автор
16.04.2024 09:23+1Кхм... Я прям не знаю, что сказать. Теперь и я задумался о личности автора... Не буду даже пытаться объяснить, как так вышло. Но я уже записался на операцию по изменению точек крепления рук.
И в наказание самому себе за такой ужас, я прокликал все строчки по 10 раз. А после, как и подобает в таких случаях, «аффтар выпил йаду». Хотя я уже и после первого этапа экзекуции был скорее мертв, чем жив, так что яд не подействовал, ибо то, что мертво, умереть уже, к сожалению, не может.
Ну и, как говорится, приношу свои извинения за доставленные неудобства.
Batalmv
16.04.2024 09:23+2Понижать ЗП - ну такое. Работать после такого он точно не станет лучше, "душой" компании тоже наверное перестанет быть (но это не важно). Плюс общая производительность команды не вырастет, тогда получается вам надо страдать за деньги вашего работодателя, на что вам, по хорошему плевать.
Ваша ответственность как тим лида - работа, которую делает команда. Вопросами ее окупаемости и прибыльности занимаются другие люди за другие деньги. В данном случае мне кажется правильным будет постановка вопроса "что не так?" именно в контексте вашей ответственности
Варианты ответа (ну я в деталях ваших раскладов не знаю):
Сотрудник говнокодит и из-за этого страдают остальные. Но тут важно понимать, действительно ли страдают. Может в реальности никто не сидит из-за одной "паршивой овцы" по ночам, сроки не горят - тогда чего страдать.
Команда валится по срокам, но у вас нет вакансии. Тогда опять же - если вы уверены, что все это из-за одного low performer'a (что сомнительно), то надо решать проблему глобально. Возможно сроки просто неадекватные
Это просто ваше всоприятие. Ну сидит, ну не делает. И вас это "типает". Но в целом все ОК. Так перестаньте на это триггериться
Что делать:
Можно уволить, но лучше сначала найти замену. Да, я понимаю, что это не всегда реально, но главное это понять - а точно сможете заменить "бойца" на существенно лучшего. Потому что нельзя говорить "нет", надо просто говорить "да" чему-то другому
Можно поговорить, но если нет hard skills - не поможет
Можно найти другие задачи. Пусть делает чего попроще
Ну и надо понимать, в чем проблема. В скорости или в качестве. Реально ли это улучшить? Может он просто нуждается в "метологической помощи"?
------------------------
Из своего опыта - low performer, не уволенный сразу, почти всегда просто накапливает "жопу". Случаи роста над собой ... я даже не уверен, что вспомню
zubrbonasus
16.04.2024 09:23Мне не понятно почему все права принадлежат компании, а у работника прав кот наплакал. Логично когда и компания и работодатель обладают равными правами, где каждый имеет права сменить работу/работника. Как у компании могут быть ошибки найма, так и у сотрудника могут быть ошибки выбора компании и т.д. Но важно отметить: если в трудовых отношениях синергия не случилась смысла продолжать отношения нет. Разошлись и каждый ищет лучшую жизнь.
ssv32
16.04.2024 09:23дать больше зарплату и не мешать работать измерениями производительности.
(непонятно в чём конкретно "…неэффективного разработчика…" ну допустим делает чуть медленнее и что?, если по итогу закрывает задачу - ок, если вкладывается в срок который ОН САМ оценил хорошо тоже (это предсказуемо, можно прогнозировать сроки), просто задачи будут делаться с учётом его скорости работы. Тим лид может думать что сделает задачу быстрее сам но он же не будет работать за всех работников 1 )
"Исключение. Оно же — увольнение. Возможно, это наилучший выход как для компании, так и для самого сотрудника. Он сможет найти работу, которая лучше соответствует его навыкам, а команда — повысить свою эффективность. " - да он сам работник, разберётся, зачем вам за него решать
- если команда может +\- спрогнозировать сроки и уложиться в них, это хорошо.
А если перегибать с эффективностью получите загнанных лошадей
sshmakov
16.04.2024 09:23А может тимлид просто неадекватно оценил сложность и сроки задачи? Такой вариант не рассматривается?
napolskih
16.04.2024 09:23Конечно может. У тимлида искажения, он обычно недооценивает. Оценивать должны исполнители и хорошо когда в целом они попадают и плохой знак когда регулярно ошибаются. Тимлид как раз должен помочь учесть риски, задать наводящие вопросы.
На самом деле, это все настолько тонкая материя.
Waltasar
16.04.2024 09:23Смотря какая должность у этого хорошего парня. Если это вечный джун, который является душой компании, то может и трогать его не стоит. Но к мидлу/сеньору должны возникнуть серьёзные вопросы.
Archi_Pro
16.04.2024 09:23Очень мне нравится эта статья, спасибо!
Экономические пассажи выше всяких похвал!
Бизнес, деньги, игры с нулевой суммой.
Экономические отношения и мотивации - очень так радикально и идеалистически, между тем господин Кудрин попал в Яндекс на зп в ярд в год, минуя алгоритмическую секцию, такие дела.
А вас там как?
Аудит проектов проводится? Ну там какие скилы нужны для выполнения, аудит скилов команды? Ассессмент членов команды? Матрица компетенций есть? А если найду?
Смотрите кого у куда можно раскачать и в какие сроки, кому не хватает хардов кому софтов, софты кстати как качать?
Тикиты в джирочке с дифинишин оф дан?
Исполнителям понятно что и как делать и ради чего (или только ради зп?)
nronnie
16.04.2024 09:23вы будете платить ему из денег, заработанных его коллегами
Можно подумать, что если ему не платить, то его деньги достанутся упомянутым коллегам.
Baobab33
16.04.2024 09:23Ну раз душа компании , в Лиды его. Готовь заместителя, через пару лет софты прокачает твоим начальником станет ) Если серьезно, возможно путь тех. менеджера это то что ему нужно. Конечно, вопрос, почему он плохой код пишет, не может, не хочет, не интересно. Если 2- 3 , точно в менеджеры )
dmitrygus
16.04.2024 09:23Есть коллега, который пишет медленно. Прям порой долго. Но в его коде редко бывают ошибки. Если он пишет какой то сервис или тулзовину в одиночку, то после релиза в 9 случаях из 10 его софт будет работать соазу без косяков. Не раз были ситуации, когда запускают его сервис и забывают о нем, пока какую-то фичу не понадобится добавить. У него даже есть фанаты среди заказчиков - просят что бы им писал именно он. А ещё у него есть знакомый, на которого он раньше работал, и который имеет свой штат разрабов, но иногда обращается к нему, что бы он ему что то написал, потому что "мои олухи что-нибудь гапортачат"
W_Lander
16.04.2024 09:23I'm harmless gangster coder:
int foo(uint32_t val){
if(val != 0) return val;
return val;
}
R0bur
В рабочее или в личное время? За свой счёт или за счёт нанимателя?
sergiorykov
Работодатель платит за приложение ваших компетенций и навыков (софт и хард) к созданию дополнительной ценности - писать код, тесты, пайплайны CI/CD, дебаг, улучшать обслуживаемость систем через логи, документацию, обучение коллег) - это на низком уровне, чем выше ваши навыки и ответственность в команде - компании, тем значительнее меняется понимание а какую ценность вы на самом деле создаете для бизнеса.
Откуда вы берете навыки - здесь несколько путей. Если вас берут с одного стека, а компания в другом - то тут взаимные обязательства - с них вас обучить, с вас обучиться. Если потребности команды в скилах меняются - а они на самом деле только растут - с ростом продукта, пользователей, сложности технологий. поэтому усидеть на стуле с текущим скилсетом невозможно. поэтому компания часто предлагает инструменты для повышения своей компетенции - оплата книг, обучений, внутренние митапы, менторство, 1:1 с тимлидом, с экспертом вашего комьюнити, где-то дают писать на хабр или в конфах выступать, где-то выделяет 10% времени на самообучение на работе по вашему ИПР, или дни для всей команды на эксперименты, или-или.
Ваша ответственность - понять свою стратегию развития, согласовать свой ИПР с тимлидом - чтобы и команде это было нужно, и вам интересно и полезно для карьеры. поэтому вы работаете и на настоящее и на будущее. здесь - только усилия с двух сторон - с вашей - это в том числе действия в нерабочее время. это может быть прохождение курса, купленного компанией, дома, или чтение проф литературы, или пет проекты, или-или. если нет возможности - то от этого будет тормозиться ваш карьерный трек, это к сожалению следствие - что количество переходит в качество, кто больше инвестирует в себя, тот быстрее растет. Компания может оказаться, что растет быстрее ваших навыков, или наоборот - вы. В одном случае - вы можете стать как герой в этой статье, в другом - повышение ответственности, сложности задачи и тд.
olegchir
по трудовому кодексу, сотрудника всегда берут на выполнение очень конкретного набора задач. Если задачи меняются, работник вплане отказаться от изменения как профиля задач, так и своего скиллсета, если они значительно отличаются от указанного в трудовом договоре. За это его уволить нельзя.
если же если какая-то деятельность (описанная в договоре) требует повышение навыков работника, то работодатель обязан организовать обучение в рабочее время. Не может, а обязан.
Подробнее можно прочитать в "Трудовой кодекс Российской Федерации" от 30.12.2001 N 197-ФЗ (ред. от 06.04.2024)
alysnix
за чей угодно. если вы не "тяните", а разговор тут об этом, то наниматель имеет полное моральное, не говоря уж об экономическом, право попросить вас из коллектива.
бизнес - не богадельня. не тяните, или подтянитесь, или найдите себя в другом месте.
R0bur
Всё правильно. Но работник же не свалился на голову нанимателя? Наверное, он прошёл через собеседования, и нанимателя устроила его квалификация. Тогда проблема "дошлифовки" навыков и знаний, как правильно замечено в комментарии sergiorykov, является предметом договорённости между нанимателем и работником. И естественно, наниматель должен быть озабочен ею не меньше работника. Не зря в общепризнанных методологиях управления ИТ имеются процессы, предусматривающие повышение квалификации персонала. В общем, наниматель должен осознавать свою ответственность за доведение компетенций работника до необходимого ему уровня, планировать на это время и деньги организации. А не отправлять "изучать перспективные технологии" (сферические в вакууме) "на домашних проектах в свободное от работы время".
Если же работник "морально разложился", то тут по КЗОТу - тоже нет особенных проблем.
Особый случай, когда сотрудник может быть мало продуктивным с точки зрения разработки, но быть "душой" команды, который "вдохновляет и за собой ведёт". Тогда его вклад в успех продукта - не меньше, чем кодеров. Может быть, стОит тогда создать для него специальную должность в команде, чтобы не было конфликта, кто чем должен заниматься?
alysnix
с душами команды надо разбираться конкретно, без обобщений. как я уже упомянул, "душа команды" - может оказаться просто манипулятором.
>Наверное, он прошёл через собеседования, и нанимателя устроила его квалификация.
ну прошел, это ничто не меняет. это ж не церковный брак, и "право на развод" - естественное право. "работодатель" в таких случаях, вообще не пойми кто. а конкретные люди, что должны тянуть "душу команды", просто могут не иметь на это времени или даже желания(ну хотя бы делать это без материальной компенсации).
хочешь развиваться - флаг в руки. не хочешь - дверь вон там. это честно.
R0bur
В статье говорится, что "душа команды" - это тот
То есть полезный член команды, хоть и не разработчик. Просто взять и уволить его - это снизить эффективность работы команды. В такой ситуации разумное решение - документально закрепить роль этого человека, то есть создать должность конкретно под него. Так будет лучше для всех. Руководитель должен будет понимать, что в команде N разработчиков, а не N+1, разработчики будут понимать, что на вклад этого человека в код продукта рассчитывать не стОит, да и самому человеку будет комфортно.
Из Вашего же комментария можно сделать вывод, что речь идёт о каком-нибудь не совсем компетентном родственнике гендиректора. В этом случае есть три варианта:
купить компанию и уволить гендиректора с родственниками;
уволиться самому;
радоваться, что этот сотрудник "просто душка" (как написано в тексте статьи), а не посылает своих коллег за кофе и печеньем.
alysnix
родственник директора, брат любовницы владельца бизнеса, теща главбуха и так далее.
ну не знаю... я вот лично никогда не работал в командах, где нужно было бы вводить должность штатного семейного психолога:) а по сути этот "просто душка" им и является.
конфликтов вообще быть не должно, не должно быть для них почвы, продуктивность должна определяться компетенцией и нормальными условиями труда, а программировать "на поднятом настроении" - так можно слишком увлечься, и начать принимать стимуляторы и прочие вещества, просто для поднятия духа.
R0bur
Ещё и от размера команды зависит. Если в ней 3-4 человека, то тут каждый должен вносить реальный вклад в продукт. А если около десятка человек, то иметь выделенного "интегратора" может оказаться выгоднее, чем подбирать состав с учётом психологической совместимости.
R0bur
В восемнадцатой главе "Романа об управлении проектами проектами" Тома Демарко рассказывается о таком работнике - маэстро Диньяре, который не производит впечатления сильного разработчика и много времени проводит за праздными разговорами с коллегами. Автор назвал его "человеком-катализатором", а его роль в проекте - поддержание здоровой доверительной атмосферы в коллективе - одной из наиболее важных.
alysnix
как православный батюшка на фронте, короче.
Keeper10
Эрик Рассел. "Немного смазки"
http://www.lib.ru/INOFANT/RASSEL_E/minor.txt