Практически у любой современной компании есть, как минимум, свой сайт. А может быть и несколько сайтов. Компании побольше организуют большие порталы, на которых не только представлена развёрнутая информация об их продуктах и услугах, но и множество сервисов. Есть компании, которые создают свою IT-продукцию, но при этом IT — не основной вид их деятельности. А есть компании, которые занимаются исключительно разработкой ПО.
В любом случае, каждой компании в той или иной мере приходится каким-то образом решать вопрос обслуживания собственных программных ресурсов, будь то сайт-визитка из трёх страниц или собственный программный продукт. Если разработка ПО не является основным «занятием» компании, она, как правило, отдаёт разработку на сторону (аутсорс) или нанимает одного-двух айтишников, далеко не всегда программистов. Если же направление деятельности компании того требует, создаются собственные отделы разработки. Речь в данном топике пойдёт как раз о собственных, но небольших командах разработчиков (5-7 человек). У автора имеется семилетний опыт найма программистов, организации их работы и управления программными проектами, хотя, конечно, не всегда удачный. Хотелось бы поделиться накопившимися соображениями с сообществом и получить комментарии. Возможно, кому-то они и пригодятся.
Будут рассмотрены варианты распределения обязанностей программистов в небольшом отделе разработки в разных «измерениях». В рамках отдела это распределение, конечно же, может быть смешанным, и один программист может играть сразу несколько ролей. Более того, думаю, «чистых» типов практически не существует в природе. По крайней мере, это касается небольших групп программистов. Итак:
«Саппортники» — программисты, выполняющие множественные мелкие задачи и общающиеся с «внешними» сотрудниками (по отношению к отделу разработки). Их можно всё время отвлекать, что-то просить, звонить им и писать. Они должны быть всё время доступны (или в рабочее время). Для облегчения их работы можно использовать системы тикетов — обращений, накапливающихся в пуле и выполняемых в соответствии с приоритетом. Если задача крупная — она передаётся «саппортником» так называемому «проектнику».
«Проектники» — программисты, выполняющие крупные задачи, требующие высокой концентрации. Этих программистов нельзя отвлекать от работы. Они всё время пишут что-то большое и сложное. Мелкие пожелания и требования при этом собираются «саппортниками». При работе в шумных офисных помещениях «проектников» имеет смысл отпускать работать домой, так как им требуются тишина и покой.
Деление на «саппортников» и «проектников» может быть представлено в виде шкалы. Крайняя степень «саппортника» — сотрудник техподдержки в call-центре. Крайняя степень «проектника» — системный архитектор, проектирующий на UML. Но в чистом виде эти крайности в небольших командах обычно не встречаются.
На втором месте, пожалуй, деление программистов по специализации — языкам и технологиям. В области разработки сайтов это, как правило, верстальщики (HTML/CSS), фронтэндники (JavaScript, ActionScript) и бэкэндники (PHP/MySQL).
Если у компании несколько отдельных проектов (например, несколько сайтов), имеет смысл назначить ответственных за каждый из них. В этом случае, область ответственности каждого сотрудника может быть чётко определена, но для такой работы каждый программист должен быть «универсалом».
Вычитал в своё время в книге "Thinking in Java" и со временем понял, что в условиях объектно-ориентированной разработки такой подход крайне полезен. Архитектор определяет структуру продукта, объекты и классы. Создатели классов их реализуют, а пользователи «соединяют» затем в конечный код. Это очень удобный вариант организации программирования, но, к сожалению, мне только приходилось наблюдать его со стороны.
В любом случае, каждой компании в той или иной мере приходится каким-то образом решать вопрос обслуживания собственных программных ресурсов, будь то сайт-визитка из трёх страниц или собственный программный продукт. Если разработка ПО не является основным «занятием» компании, она, как правило, отдаёт разработку на сторону (аутсорс) или нанимает одного-двух айтишников, далеко не всегда программистов. Если же направление деятельности компании того требует, создаются собственные отделы разработки. Речь в данном топике пойдёт как раз о собственных, но небольших командах разработчиков (5-7 человек). У автора имеется семилетний опыт найма программистов, организации их работы и управления программными проектами, хотя, конечно, не всегда удачный. Хотелось бы поделиться накопившимися соображениями с сообществом и получить комментарии. Возможно, кому-то они и пригодятся.
Будут рассмотрены варианты распределения обязанностей программистов в небольшом отделе разработки в разных «измерениях». В рамках отдела это распределение, конечно же, может быть смешанным, и один программист может играть сразу несколько ролей. Более того, думаю, «чистых» типов практически не существует в природе. По крайней мере, это касается небольших групп программистов. Итак:
«Саппортники» и «проектники»
«Саппортники» — программисты, выполняющие множественные мелкие задачи и общающиеся с «внешними» сотрудниками (по отношению к отделу разработки). Их можно всё время отвлекать, что-то просить, звонить им и писать. Они должны быть всё время доступны (или в рабочее время). Для облегчения их работы можно использовать системы тикетов — обращений, накапливающихся в пуле и выполняемых в соответствии с приоритетом. Если задача крупная — она передаётся «саппортником» так называемому «проектнику».
«Проектники» — программисты, выполняющие крупные задачи, требующие высокой концентрации. Этих программистов нельзя отвлекать от работы. Они всё время пишут что-то большое и сложное. Мелкие пожелания и требования при этом собираются «саппортниками». При работе в шумных офисных помещениях «проектников» имеет смысл отпускать работать домой, так как им требуются тишина и покой.
Деление на «саппортников» и «проектников» может быть представлено в виде шкалы. Крайняя степень «саппортника» — сотрудник техподдержки в call-центре. Крайняя степень «проектника» — системный архитектор, проектирующий на UML. Но в чистом виде эти крайности в небольших командах обычно не встречаются.
Фронтэнд и бэкэнд-программисты (деление по специализации)
На втором месте, пожалуй, деление программистов по специализации — языкам и технологиям. В области разработки сайтов это, как правило, верстальщики (HTML/CSS), фронтэндники (JavaScript, ActionScript) и бэкэндники (PHP/MySQL).
Попроектное деление
Если у компании несколько отдельных проектов (например, несколько сайтов), имеет смысл назначить ответственных за каждый из них. В этом случае, область ответственности каждого сотрудника может быть чётко определена, но для такой работы каждый программист должен быть «универсалом».
Создатели и пользователи классов
Вычитал в своё время в книге "Thinking in Java" и со временем понял, что в условиях объектно-ориентированной разработки такой подход крайне полезен. Архитектор определяет структуру продукта, объекты и классы. Создатели классов их реализуют, а пользователи «соединяют» затем в конечный код. Это очень удобный вариант организации программирования, но, к сожалению, мне только приходилось наблюдать его со стороны.