Как ваша команда разработчиков программного обеспечения структурирована с точки зрения организационной структуры? - PullRequest
0 голосов
/ 15 мая 2009

Я хочу знать, как ваши текущие команды структурированы с точки зрения отчетности и организационной структуры. Если кто-то может предоставить названия различных ролей, используемых в вашей организации, это будет здорово.

Полагаю, я полностью запутался в этом вопросе. Я также хотел знать, какой будет идеальная установка, вроде диаграммы организации вашей мечты.

Ответы [ 8 ]

3 голосов
/ 15 мая 2009

Я работаю в небольшой софтверной компании; у нас только два разработчика. До того, как я начал писать программное обеспечение, я изучал психологию и после этого получил степень магистра делового администрирования, поэтому я могу сказать вам по существующей литературе, что среднестатистический человек может справиться с 2-7 вещами с оптимальным значением 4-5. Итак, ваш лучший выбор - добраться до группы из 5 или меньше. Если у вас есть 5 команд, один человек может управлять всеми 5 из этих команд. Если у вас 25 команд, один человек управляет каждой из этих команд, а один человек управляет 5 менеджерами.

Лично у меня всегда будет два программиста, работающих за одним столом. Я и мой ведущий разработчик работаем за очень большим столом. Мы сталкиваемся друг с другом, и нет разделителя. Мы отлично ладим, а простота сотрудничества делает нас очень эффективными. Вероятно, у меня всегда будет 3-4 программиста, работающих в одном офисе одновременно. Я буду держать их лицом друг к другу, чтобы вы по-прежнему уединялись и чтобы было легко и удобно смотреть в глаза и задавать вопросы.

Кроме того, я не буду держать своих программистов в общей зоне. Отвлечение может быть чрезвычайно дорогостоящим для программистов. Мне нравится, что у них есть возможность закрыть свои двери и сказать: «Сегодня меня никто не трогает ... Я в зоне!»

Наконец, в идеале, разработчики должны работать над как можно меньшим количеством проектов за один раз. Переключение контекста убивает в среде разработки. Простое отвлечение может стоить целых часов производительности. Переключение контекста может занять несколько часов. Поскольку мы такие маленькие, мы часто работаем над 5 или 6 проектами в один и тот же день. Крупные компании посвящают программистов почти исключительно одному проекту, и это сокращает потери эффективности из-за переключений контекста.

2 голосов
/ 15 мая 2009

В Microsoft Windows и офисных организациях группы разработки продуктов (в основном) состоят из людей на три роли: управления программами (PM), тестировщиков и разработчиков.

Конечно, разработчики несут ответственность за разработку. Команда тестирования отвечает за разработку функциональных и связанных тестов и инфраструктуры; и запустить тесты, чтобы найти ошибки. Очень мало тестов проводится вручную - мы тратим много времени на автоматизацию. Это включает в себя разработку вещей, чтобы сделать их более легко тестируемыми.

Роль управления программой отвечает за коммуникацию, координацию и планирование. Это будет означать разные вещи для разных команд. Но они - клей, который скрепляет все вместе.

С точки зрения оргструктуры, все очень условно. У большинства менеджеров от 3 до 9 человек, подчиняющихся им - не слишком плоско, но не слишком глубоко. Очень плоское органное дерево не будет хорошо работать в Microsoft (это не значит, что они плохие, но с культурной точки зрения наличие более 9 прямых отчетов является сложной задачей).

1 голос
/ 15 мая 2009

У нас есть:

Владелец.

Разработчики (технически владелец - один из разработчиков) .

Без менеджеров среднего звена, без должностей, без лишних формальностей.

У меня работает.

0 голосов
/ 15 мая 2009

У нас есть отношения по подбору персонала, которые отличаются от команд, которые выполняют работу. У нас есть три команды Scrum, у которых есть пара владельцев продуктов, но люди в этих командах не обязательно отчитываются перед кем-то из своей команды. Старшие разработчики (трое из нас) подчиняются директору по инжинирингу, а остальные остальные разработчики (шесть) подчиняются двум старшим разработчикам. Тем временем все тестеры и SDET отчитываются перед старшим SDET. Итак, с точки зрения управления персоналом, есть три менеджера среднего звена, которые подчиняются директору по инжинирингу, а также один старший разработчик, у которого нет никаких отчетов, и наш архитектор. Эти пятнадцать или около того людей, в свою очередь, распределены по трем командам Скрам, которые не обязательно соответствуют организационной структуре. Команды Scrum отвечают за ежедневное определение того, над чем должны работать люди, в то время как отношения по подбору персонала связаны с эффективностью работы, любыми проблемами, которые могут возникнуть у людей, карьерным ростом и тому подобным.

0 голосов
/ 15 мая 2009

[Директор] <-> [PM] <-> [Разработчик, тестер]

[Разработчик] <-> [Директор]

Довольно плоский.

0 голосов
/ 15 мая 2009

По большей части мы настроены так:

Manager <- CMMI Facilitator <- Инженер-программист I-IV </p>

Менеджер <- Системный инженер </p>

Это довольно простая установка, но она хорошо работает.

0 голосов
/ 15 мая 2009
  • Директор по разработке программного обеспечения
  • Главный инженер-программист
  • Старший инженер-программист
  • Инженер-программист II
  • Инженер-программист I

У нас также есть должности «Team Lead» и «Project Engineer». Я уверен, что есть и другие, которые я забыл, но сегодня утром мне еще не хватило кофе.

0 голосов
/ 15 мая 2009

У меня в компании очень плоская структура управления. В нашей команде разработчиков нет никакой иерархии; все разработчики программного обеспечения находятся на одном уровне и подчиняются непосредственно вице-президенту по разработке программного обеспечения. Иногда одного из нас привлекают к руководству проектом, но в нашей компании это просто означает другой набор обязанностей, а не продвижение. Это круто, потому что наша команда разработчиков стала меритократией.

...