Comments 17
так как же ее все-таки собрать)?
Собрать толпу IT-специалистов не так уж сложно, сложнее отсеять левых людей, и совсем сложно (хоть и не невозможно) — сделать из них команду.
Статья не призвана дать готовый универсальный ответ, но содержит ряд идей, которые, надеюсь, пригодятся в этом сложном деле.
Статья не призвана дать готовый универсальный ответ, но содержит ряд идей, которые, надеюсь, пригодятся в этом сложном деле.
Речь идет о команде, а не о толпе!
Что значит «левый», а может он слишком «правый»?
Реальный пример, приводит project manager (PM) молодого бойца, говорит он такой толковый все знает, все хочет новое постигать-берем!..
Есть team leader(TL), который общается с этим парнем и понимает, что его уровень очень далек о того что описал PM и на данный момент такой сотрудник не нужен.Возникает вопрос, для PM это свой человек, для TL он «левый». Возможно и обратная ситуация.Как в таких случаях предложите поступать?
А завязка на чем? У PM язык подвязан и он тянется к таким же, TL предпочитает хороших технарей.В таких случая идеальная команда будет, это команда разнообразных людей, потому что, тот кто сегодня левый завтра будет очень своим. Гласс кстати в своих трудах хорошо описывает эти сутации, да и Тони ДеМарко в Peopleware, так что не думаю что пост откроет кому-то глаза…
P.S: Мы вышли из этой ситуации просто, вся команда по очереди проинтервьюировала парня и вынесла вердикт, но не всегда так бывает.
Реальный пример, приводит project manager (PM) молодого бойца, говорит он такой толковый все знает, все хочет новое постигать-берем!..
Есть team leader(TL), который общается с этим парнем и понимает, что его уровень очень далек о того что описал PM и на данный момент такой сотрудник не нужен.Возникает вопрос, для PM это свой человек, для TL он «левый». Возможно и обратная ситуация.Как в таких случаях предложите поступать?
А завязка на чем? У PM язык подвязан и он тянется к таким же, TL предпочитает хороших технарей.В таких случая идеальная команда будет, это команда разнообразных людей, потому что, тот кто сегодня левый завтра будет очень своим. Гласс кстати в своих трудах хорошо описывает эти сутации, да и Тони ДеМарко в Peopleware, так что не думаю что пост откроет кому-то глаза…
P.S: Мы вышли из этой ситуации просто, вся команда по очереди проинтервьюировала парня и вынесла вердикт, но не всегда так бывает.
Всё зависит от того, на какую позицию принимается человек — на техническую или в качестве ассистента проект-менеджера. Соответственно, какие компетенции ему нужны, и кто из сотрудников должен проверять их наличие.
Не обязательно интервьюировать парня всей команде. Но после рекомендации PM'a стоит устроить собеседование с TL'ем, который сможет более объективно оценить техническую толковость.
Не обязательно интервьюировать парня всей команде. Но после рекомендации PM'a стоит устроить собеседование с TL'ем, который сможет более объективно оценить техническую толковость.
я говорил о конфликте интересов, что не столь важно.Вы так и не ответили, что подразумеваете под словом «левый».
Насчет проверки профпригодности командой скажу, что с тех пор это стала частая практика.Особенно когда серьезно настроили Agile в команде.Проявляется много интересных вещей, ведь и TL ошибается...)
Насчет проверки профпригодности командой скажу, что с тех пор это стала частая практика.Особенно когда серьезно настроили Agile в команде.Проявляется много интересных вещей, ведь и TL ошибается...)
Я здесь не увидела конфликта — ведь и PM'у важно, чтобы человек справлялся со своими обязанностями и был эффективен на своем месте. Другое дело, что на него лучшее впечатление могут производить люди с подвешенным языком.
Насчет интервью с каждым из команды — согласна, что это может быть интересная и полезная практика.
Что значит «левый»? Это человек, который скорее тормозит работу команды (а то и откатывает назад). чем двигает вперед. Из-за лени, безответственности, неумения или нежелания посидеть и разобраться самому (хотя это тоже к лени), причин можно назвать много. При этом человек может нам подходить по техническим навыкам, но с таким набором личных качеств едва ли будет полезен для общего дела.
Насчет интервью с каждым из команды — согласна, что это может быть интересная и полезная практика.
Что значит «левый»? Это человек, который скорее тормозит работу команды (а то и откатывает назад). чем двигает вперед. Из-за лени, безответственности, неумения или нежелания посидеть и разобраться самому (хотя это тоже к лени), причин можно назвать много. При этом человек может нам подходить по техническим навыкам, но с таким набором личных качеств едва ли будет полезен для общего дела.
более того, статья на самом деле не говорит о том, как собрать команду, а только о том, кого в команду брать не надо. А вот о том, кого надо, и где его взять(а это самое интересно) собственно ни слова.
Ведь во многих случаях достаточно посидеть несколько дней (ночей, часов, недель) с учебником, чтобы освоить недостающую для должности технологию.Вы именно так писали эту статью, и вот что получилось?
Не согласен.
>> Программисты — это не только ценный код
Если вы берете на работу программиста, то для Вас ценностью является именно код. ИМХО, Вы впустую тратите свое время и время соискателя разговаривая с человеком на отвлеченные темы. Никто не сможет в течении этих разговоров понять, приживется ли работник в коллективе. Для этого есть первые 2-3 месяца работы(тестовый период). Например, если ко мне придет программист от которого будет вонять, но он будет классно писать код, я его обязательно возьму. За тестовый период он начнет или его заставят следить за собой(если конечно коллектив соответствующий).
Про IT-руководителей.
Есть менеджеры проектов, а есть ведущие проектов. «Бумажками» занимается как раз менеджер проектов, но он не руководитель. Руководителем как раз является именно высококвалифицированный IT-спец.
«Средний» специалист никогда не сможет занимать место ведущего проекта, потому что большинство IT-шников — технократы, и основой авторитета у них является знание и умение, а не коммуникабельность и прочая HR-фигня.
>> Программисты — это не только ценный код
Если вы берете на работу программиста, то для Вас ценностью является именно код. ИМХО, Вы впустую тратите свое время и время соискателя разговаривая с человеком на отвлеченные темы. Никто не сможет в течении этих разговоров понять, приживется ли работник в коллективе. Для этого есть первые 2-3 месяца работы(тестовый период). Например, если ко мне придет программист от которого будет вонять, но он будет классно писать код, я его обязательно возьму. За тестовый период он начнет или его заставят следить за собой(если конечно коллектив соответствующий).
Про IT-руководителей.
Есть менеджеры проектов, а есть ведущие проектов. «Бумажками» занимается как раз менеджер проектов, но он не руководитель. Руководителем как раз является именно высококвалифицированный IT-спец.
«Средний» специалист никогда не сможет занимать место ведущего проекта, потому что большинство IT-шников — технократы, и основой авторитета у них является знание и умение, а не коммуникабельность и прочая HR-фигня.
UFO just landed and posted this here
Что касается поговорить на отвлеченные темы — это не моя придумка. Такой совет я услышала от руководителя крупной международной IT-компании. Для него это работает. Знаю еще одного директора IT-компании, для которого важно выцепить «своего» человека еще на этапе собеседования.
Для многих других руководителей это действительно пустая трата времени. Кому-то и нескольких месяцев мало, чтобы понять, что перед ним за человек и есть ли от него польза. Так что совет не универсален — это да.
Что касается ценнного кода. Допустим, есть классный программер, который пишет код, близкий к гениальному. Но делает это по несколько строчек в месяц, когда у него есть вдохновение. А в остальное время — просто просиживает рабочие часы.
Конечно, рано или поздно это выявится, и человек будет уволен. Но почему бы не отсеять такого малополезного сотрудника еще до приема на работу?
Что касается менеджеров проектов и ведущих проектов, в статье именно об этом идет речь — в примере с Motorol'ой. Технический руководитель и руководитель-администратор — каждый должен быть на своем месте и обладать соответственным набором компетенций. Главное — не заставлять высококвалифицированного IT-спеца разгребать бумажки.
Для многих других руководителей это действительно пустая трата времени. Кому-то и нескольких месяцев мало, чтобы понять, что перед ним за человек и есть ли от него польза. Так что совет не универсален — это да.
Что касается ценнного кода. Допустим, есть классный программер, который пишет код, близкий к гениальному. Но делает это по несколько строчек в месяц, когда у него есть вдохновение. А в остальное время — просто просиживает рабочие часы.
Конечно, рано или поздно это выявится, и человек будет уволен. Но почему бы не отсеять такого малополезного сотрудника еще до приема на работу?
Что касается менеджеров проектов и ведущих проектов, в статье именно об этом идет речь — в примере с Motorol'ой. Технический руководитель и руководитель-администратор — каждый должен быть на своем месте и обладать соответственным набором компетенций. Главное — не заставлять высококвалифицированного IT-спеца разгребать бумажки.
Не согласен что IT-шники особые.
— Все специалисты особые, никогда хороший IT-шник не поймёт хорошего (например) каменщика.
Собрать сложно любую команду специалистов.
— Чем и отличается специалист (даже дворник, но хороший) от простого рабочего (который просто приходит нарабатывать часы) что он имеет свой подход, свой опыт, и хочет сделать как лучше, а чтоб сделать лучше не в одиночку а в команде надо «ужиться» с другими специалистами.
Очень трудно отличить лентяев от ценных кадров.
— Работал как-то в конторке, за час успевал переделать то что вчера 8 часов делал коллега, и ещё за пол часа делал то что требовалось от меня. Меня быстро выгнали потому что я слишком много отдыхаю, а вот коллега работает, ему даже зарплату подняли (в итоге я рад что не работаю с этими идиотами, да и проект они само собой завалили, не прошло и месяца)
В итоге проблема упирается в одну.
— Не проблема найти хорошего IT-шника и хорошего начальника, проблема в том что начальник должен быть подкованным и в управлении, и в IT (обычно это несовместимые качества, ибо IT-шники не редко «слабы» в сплочении команды, а хорошие начальники которые могли бы сколотить команду не могут оценивать что в этот момент творится с кодом)
— Все специалисты особые, никогда хороший IT-шник не поймёт хорошего (например) каменщика.
Собрать сложно любую команду специалистов.
— Чем и отличается специалист (даже дворник, но хороший) от простого рабочего (который просто приходит нарабатывать часы) что он имеет свой подход, свой опыт, и хочет сделать как лучше, а чтоб сделать лучше не в одиночку а в команде надо «ужиться» с другими специалистами.
Очень трудно отличить лентяев от ценных кадров.
— Работал как-то в конторке, за час успевал переделать то что вчера 8 часов делал коллега, и ещё за пол часа делал то что требовалось от меня. Меня быстро выгнали потому что я слишком много отдыхаю, а вот коллега работает, ему даже зарплату подняли (в итоге я рад что не работаю с этими идиотами, да и проект они само собой завалили, не прошло и месяца)
В итоге проблема упирается в одну.
— Не проблема найти хорошего IT-шника и хорошего начальника, проблема в том что начальник должен быть подкованным и в управлении, и в IT (обычно это несовместимые качества, ибо IT-шники не редко «слабы» в сплочении команды, а хорошие начальники которые могли бы сколотить команду не могут оценивать что в этот момент творится с кодом)
По-моему, руководитель IT-команды должен быть не только хорошим управленцем, но и достаточно авторитетным специалистом для ее членов (т.е. не менеджер, взятый из абстрактных менеджеров, а менеджер, выбранный из IT-специалистов). Иначе может выйти, что задача, поставленная, вроде-бы, грамотно, не может быть выполнена без длительного обсуждения с командой и множества поправок, приближающей ее к реальности (причем не факт, что команда будет компетентна в этом вопросе :)). В итоге руководитель будет скорее малоуважаемым «представителем» команды вовне (который, к тому же, будет постоянно обговаривать изменения, внесенные командой, с внешним миром).
Ну а IT-спецы, скорее, будут куда лучше себя чувствовать, если к ним относятся не как к зацикленным на работе людям, а как к любым другим сотрудникам — т.е. с нормальным графиком работы — иначе они так же быстро горят, как и любые другие. Даже если они 100% своего времени занимаются чем-то IT-ориентированным, это не значит, что эти 100% они должны тратить непосредственно на работу для компании — важно, чтобы они переключалисьь и занимались чем-то интересным для себя.
Ну а IT-спецы, скорее, будут куда лучше себя чувствовать, если к ним относятся не как к зацикленным на работе людям, а как к любым другим сотрудникам — т.е. с нормальным графиком работы — иначе они так же быстро горят, как и любые другие. Даже если они 100% своего времени занимаются чем-то IT-ориентированным, это не значит, что эти 100% они должны тратить непосредственно на работу для компании — важно, чтобы они переключалисьь и занимались чем-то интересным для себя.
Sign up to leave a comment.
Как собрать IT-команду