Я считаю, что служба — это прежде всего команда людей, объединенных одной целью. То есть, по-моему, вопрос «Как сделать эффективную ИТ-службу?» эквивалентен вопросу «Как создать эффективную it-команду?».
Давно в статье Андрея Орлова я прочитал, что собрать команду — это искусство. Возможно. Понимаю, что вопрос слишком общий. И все же, я попробую в этой статье на него ответить. Надеюсь описанное мной решение послужит материалом для обмена опытом. Я описываю этот процесс с практической точки зрения, пользуясь своей практикой пройденного пути от простого программиста до топ-менеджера и теоретическими знаниями, приобретенными на этом пути.
Т.к. мой последний опыт связан с подбором команды для Start-up'ов, то по-хорошему статью надо назвать — «Поиск специалистов и создание команды в start-up'ах»
Кто-то находит Вас, как правило, это менеджер проекта, тот, кто отвечает за весь проект. Итак, топ-менеджеры, найдены, вы один из них. Ваша ответственность — это реализация ПО для проекта(ов) и эффективные решения it-проблем компании. Эта должность называется по-разному. Моя it-директор.
Вы вступаете в должность. Это не такой простой процесс, как может показаться. Потому что вы приходите в коллектив, внутри которого уже есть сформировавшиеся взаимоотношения, а видеть эти взаимоотношения мы не можем, чувствовать тоже, а с людьми придется столкнуться с первого дня, с их привычными отношениями и складом делопроизводства. Попробуйте закурить не в том месте или обидеть hr-менеджера, который по совместительству дочь собственника. Вы на минном поле, оглядитесь, будьте осторожны и вежливы и не перегибайте палку, иначе прослывете педантом.
От ваших первых шагов зависит ваша карьера и положение в обществе компании. Подчеркиваю, не от ваших профессиональных навыков, а от ваших отношений. Безусловно, эта зависимость имеет корреляцию с типом компании, я разделяю их на:
Я имею опыт создания команд в Start-up’ах, в других мной выделенных типах компаний я только наблюдал за формированием команд или наблюдал за деятельностью уже сложившихся команд.
Далее я буду говорить о Start-up’ах и формировании команды для реализации ПО для проекта.
После того как вы познакомились с менеджерами других подразделений и понимаете, для чего, вас взяли и что требуется от вас и вашей команды.
Одновременно с вступлением в должность, проведением собеседований, написанием отчетов, стратегий развития, планов и бюджетов, вы должны обеспечить инфраструктуру для управления проектами, набор инструментов, с помощью которых будет создаваться документация, осуществляться управление требованиями, храниться версии кода. Зачем все это? Я привык строить процесс разработки максимально открытым, то есть так, чтоб каждый член команды понимал свою роль, ответственность, и то что ему нужно делать здесь и сейчас для успеха проекта или итерации. Я придерживаюсь модели управления XP при управлении разработкой.
Вы выбираете технологии, вы понимаете, какие специалисты вам нужны, вы составляете вакансии и … обнаруживаете, что у компании нет сайта. Я обнаружил, что это существенно, когда меня дважды спросили об этом кандидаты, в которых я был заинтересован. Хорошо если в вашей компании есть корпоративная атрибутика, тогда вы можете взять drupal, написать пару статей и сделать сайт, разместив на хостинге друга. Мне не так повезло, атрибутики не было, я воспользовался темой от word press и знанием html. Вуаля, сайт готов за 8мь часов вами довольны в первый раз.
Не забудьте, что вы не google и даже еще не yandex, все нужно делать быстро, здесь и сейчас.
Итак, инфраструктура готова, технологии выбраны, у вас есть план запуска проекта, вы понимаете, кто вам нужен в первую очередь.
Не стесняйтесь при хорошем предложении на рынке труда:
Два этих требования позволяют сразу отсеять болтунов и неаккуратных разработчиков, не тратя время на интервью, и эти требования все равно не позволят вам увидеть Людей!
Я говорю о тех специалистах, которые к своей работе относятся очень серьезно, о тех программистах, кто не отойдет от компьютера пока не избавится от ошибки в коде, о тех, для кого баги в конце итерации — не приемлемая форма сдачи функционала. Пол Грехем называет таких людей зверьми и предлагает такой тест:
«Провести «зверский тест» легче всего, если вы уже знакомы с человеком. Просто вспомните его лицо и скажите себе «такой-то и такой-то – настоящий зверь». И если вам станет смешно, он не подходит.»
Так же я стараюсь ответить себе на вопросы во время интервью:
Беру человека, только если четыре из пяти ответов «ДА»
Наиболее эффективные по откликам толковых людей места:
Дайте понять менеджеру, кто такие программисты и что вы от них ждете:
Следите за актуальностью приоритетов подбора каждую неделю. Попросите указывать ваш email в копии отправляемых приглашений и ответов. Эти письма – репутация вашей компании в глазах специалистов, которые эти письма получают.
Стратегия развития ясна, команда сформирована. Рано расслабляться. Команда проходит определенные стадии своего развития. Мне как директору важно, чтоб команды проектов кристаллизовались. То есть были в апогее своей эффективности. Все истории, что вы слышали о успехе любого проекта, это история о работе кристаллизованной команды.
Я разделяю стадии формирования команды:
От менеджера требуется необычайная ловкость и множество уловок при проведении команды через каждую стадию.
Для себя я нашел лучшее средство разрешения конфликтов — не иметь их. Конечно так, не получится, и все же количество прецедентов можно снизить, если сделать максимально открытый процесс разработки с документированием решений и причин решений. Так же я ввожу правила чтения документации:
Жестко, но работает. Документация становится живой и все время обновляется.
Другая практика, которую использую — я стараюсь давать возможность ошибаться (приобретать опыт) членам команды и всей команде в целом. Да, это иногда приводит к конфликтам и не реализованному функционалу, и все же в таких случаях я знаю, где стелить солому :) Я заметил, что проблема решается наиболее эффективно, если разработчик с ней столкнулся лично, а не в моем описании. Лучше всего это работает в начале совместной работы для улучшения качества точности оценки разработчиками времени на реализацию функционала.
Так же для себя я нашел хорошую практику открытых отношений:
и открытой информации:
Через полгода вы вдруг обнаружите, что команда укомплектована, разработка отнимает меньше сил и времени, у Вас появляется время на развитие проектов. Ура!
Собрать команду и сделать её эффективной, ремесло? Для меня это навык, и все же я не смог ответить на этот вопрос в общем случае, надеюсь, сделал шаг в верном направлении :) Жду ваших комментариев, господа :)
Многие вопросы в этой статье не были затронуты:
В следующих сериях :)
Давно в статье Андрея Орлова я прочитал, что собрать команду — это искусство. Возможно. Понимаю, что вопрос слишком общий. И все же, я попробую в этой статье на него ответить. Надеюсь описанное мной решение послужит материалом для обмена опытом. Я описываю этот процесс с практической точки зрения, пользуясь своей практикой пройденного пути от простого программиста до топ-менеджера и теоретическими знаниями, приобретенными на этом пути.
Т.к. мой последний опыт связан с подбором команды для Start-up'ов, то по-хорошему статью надо назвать — «Поиск специалистов и создание команды в start-up'ах»
Начальные условия
Кто-то находит Вас, как правило, это менеджер проекта, тот, кто отвечает за весь проект. Итак, топ-менеджеры, найдены, вы один из них. Ваша ответственность — это реализация ПО для проекта(ов) и эффективные решения it-проблем компании. Эта должность называется по-разному. Моя it-директор.
Вы вступаете в должность. Это не такой простой процесс, как может показаться. Потому что вы приходите в коллектив, внутри которого уже есть сформировавшиеся взаимоотношения, а видеть эти взаимоотношения мы не можем, чувствовать тоже, а с людьми придется столкнуться с первого дня, с их привычными отношениями и складом делопроизводства. Попробуйте закурить не в том месте или обидеть hr-менеджера, который по совместительству дочь собственника. Вы на минном поле, оглядитесь, будьте осторожны и вежливы и не перегибайте палку, иначе прослывете педантом.
От ваших первых шагов зависит ваша карьера и положение в обществе компании. Подчеркиваю, не от ваших профессиональных навыков, а от ваших отношений. Безусловно, эта зависимость имеет корреляцию с типом компании, я разделяю их на:
- Банк
- Ретейл
- не it
- it
- Торговый порт
- Поставщик it-решений
- Государственное учреждение
- Start-up, зрелая it-компания
Я имею опыт создания команд в Start-up’ах, в других мной выделенных типах компаний я только наблюдал за формированием команд или наблюдал за деятельностью уже сложившихся команд.
Далее я буду говорить о Start-up’ах и формировании команды для реализации ПО для проекта.
После того как вы познакомились с менеджерами других подразделений и понимаете, для чего, вас взяли и что требуется от вас и вашей команды.
Создаем команду
Одновременно с вступлением в должность, проведением собеседований, написанием отчетов, стратегий развития, планов и бюджетов, вы должны обеспечить инфраструктуру для управления проектами, набор инструментов, с помощью которых будет создаваться документация, осуществляться управление требованиями, храниться версии кода. Зачем все это? Я привык строить процесс разработки максимально открытым, то есть так, чтоб каждый член команды понимал свою роль, ответственность, и то что ему нужно делать здесь и сейчас для успеха проекта или итерации. Я придерживаюсь модели управления XP при управлении разработкой.
Вы выбираете технологии, вы понимаете, какие специалисты вам нужны, вы составляете вакансии и … обнаруживаете, что у компании нет сайта. Я обнаружил, что это существенно, когда меня дважды спросили об этом кандидаты, в которых я был заинтересован. Хорошо если в вашей компании есть корпоративная атрибутика, тогда вы можете взять drupal, написать пару статей и сделать сайт, разместив на хостинге друга. Мне не так повезло, атрибутики не было, я воспользовался темой от word press и знанием html. Вуаля, сайт готов за 8мь часов вами довольны в первый раз.
Не забудьте, что вы не google и даже еще не yandex, все нужно делать быстро, здесь и сейчас.
Кто нужен?
Итак, инфраструктура готова, технологии выбраны, у вас есть план запуска проекта, вы понимаете, кто вам нужен в первую очередь.
Не стесняйтесь при хорошем предложении на рынке труда:
- Предлагать тестовые задания, но не более, чем на три-четыре часа для толкового программиста.
- Просить код, которым гордятся разработчики.
Два этих требования позволяют сразу отсеять болтунов и неаккуратных разработчиков, не тратя время на интервью, и эти требования все равно не позволят вам увидеть Людей!
Я говорю о тех специалистах, которые к своей работе относятся очень серьезно, о тех программистах, кто не отойдет от компьютера пока не избавится от ошибки в коде, о тех, для кого баги в конце итерации — не приемлемая форма сдачи функционала. Пол Грехем называет таких людей зверьми и предлагает такой тест:
«Провести «зверский тест» легче всего, если вы уже знакомы с человеком. Просто вспомните его лицо и скажите себе «такой-то и такой-то – настоящий зверь». И если вам станет смешно, он не подходит.»
Так же я стараюсь ответить себе на вопросы во время интервью:
- Этот специалист, умнее, чем я?
- Он более компетентен, чем я, в области, которой ему предстоит заниматься?
- Он сможет завершить начатое до конца? (Важен ли ему результат его работы?)
- Этот человек толковый, у него есть талант, он «зверь»?
- Может ли он работать в моей команде?
Беру человека, только если четыре из пяти ответов «ДА»
Где искать?
Наиболее эффективные по откликам толковых людей места:
- Job ресурсы
- Хабрахабр
- Агентства по найму
- Знакомые
- Знакомые уже принятых на работу
Как ставить задачи HR и что от него ждать?
Дайте понять менеджеру, кто такие программисты и что вы от них ждете:
- Резюме – сделанные проекты
- Рассказ о себе – краткий рассказ о сборке ZX Spectrum в гараже с братом
- Желаемая должность и зарплата
- Код, которым он гордиться
- Тестовое задание для выбранной должности
Следите за актуальностью приоритетов подбора каждую неделю. Попросите указывать ваш email в копии отправляемых приглашений и ответов. Эти письма – репутация вашей компании в глазах специалистов, которые эти письма получают.
Стадии прохождения команды
Стратегия развития ясна, команда сформирована. Рано расслабляться. Команда проходит определенные стадии своего развития. Мне как директору важно, чтоб команды проектов кристаллизовались. То есть были в апогее своей эффективности. Все истории, что вы слышали о успехе любого проекта, это история о работе кристаллизованной команды.
Я разделяю стадии формирования команды:
- Формирование — группа управляемая менеджером. Члены команды учатся работать друг с другом и пытаются понять свою роль в команде.
- Псевдокоманда — война за власть и контроль. Нет согласия и доверия, есть предубеждение. Управление конфликтами.
- Стабильная — прекращение деление власти, появляется доверие друг к другу.
- Кристаллизованная команда — самоуправляемая команда, в которой каждый знает свое место в проекте и всецело отдается проекту.
От менеджера требуется необычайная ловкость и множество уловок при проведении команды через каждую стадию.
Решение конфликтов и проблем внутри команды
Для себя я нашел лучшее средство разрешения конфликтов — не иметь их. Конечно так, не получится, и все же количество прецедентов можно снизить, если сделать максимально открытый процесс разработки с документированием решений и причин решений. Так же я ввожу правила чтения документации:
- Документация всегда верна
- Если документацию можно трактовать двояко, и разработчик принимает решение без вопроса ответственному лицу, то это проблема разработчика.
- Все решения и исследования документируются
Жестко, но работает. Документация становится живой и все время обновляется.
Другая практика, которую использую — я стараюсь давать возможность ошибаться (приобретать опыт) членам команды и всей команде в целом. Да, это иногда приводит к конфликтам и не реализованному функционалу, и все же в таких случаях я знаю, где стелить солому :) Я заметил, что проблема решается наиболее эффективно, если разработчик с ней столкнулся лично, а не в моем описании. Лучше всего это работает в начале совместной работы для улучшения качества точности оценки разработчиками времени на реализацию функционала.
Так же для себя я нашел хорошую практику открытых отношений:
- нет начальников, есть команды
- нет приказов, есть аргументы
и открытой информации:
- зарплаты, бюджеты
- deadline проекта
- ответственность каждого члена команды
- задачи и функции каждого члена команды
Через полгода вы вдруг обнаружите, что команда укомплектована, разработка отнимает меньше сил и времени, у Вас появляется время на развитие проектов. Ура!
Резюме
Собрать команду и сделать её эффективной, ремесло? Для меня это навык, и все же я не смог ответить на этот вопрос в общем случае, надеюсь, сделал шаг в верном направлении :) Жду ваших комментариев, господа :)
Многие вопросы в этой статье не были затронуты:
- Как проводить интервью? Рекомендую посмотреть Джоэл Сполски, у него несколько великолепных статей на эту тему.
- Как кристаллизовать команду?
- Как решать конфликты?
- Что делать, чтоб не утекли нужные проекту люди?
- ...
В следующих сериях :)
