Как определить количество программистов, необходимых для проекта


18

Как вы узнаете, сколько программистов для успеха конкретного проекта?

Компания, в которой я работаю, выполняет заказы для компаний-клиентов. Мы разработали собственную систему управления складом, которая занимается управлением запасами на основе местоположения, обработкой заказов, формированием накладных, выставлением счетов, аудитом грузов и отчетами (вероятно, 50 отчетов). Он также имеет функции сканирования штрих-кода и клиентский портал, а также десятки других небольших функций. Он также включает в себя полное время сотрудника. Он интегрируется с Quickbooks, UPS и FedEx. Он обрабатывает работу как минимум для 50 клиентов, каждый из которых немного отличается по своей функциональности. Например, мы импортируем заказы из файлов, которые отправляют клиенты, но каждый клиент отправляет свой формат файла (csv, excel, flat file и веб-сервисы), поэтому у нас есть более десятка настроек методов преобразования заказов. Экспорт это та же история.

Проект сложен и растет с каждым днем: более четверти миллиона строк кода. Это около 250 000 строк кода VB.NET, 6200 строк кода Ruby и, возможно, 5000 строк PHP. Он также имеет базу данных MySQL с около 200 таблицами.

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

В настоящее время в этом проекте есть только один программист - я сам. Я также в настоящее время делаю всю поддержку продукта для нашей компании приблизительно 75 человек. Это включает устранение неполадок и настройку новых клиентов, а также любые новые необходимые функции. Кроме того, мы пытаемся переписать все это на 100% на основе Ruby on Rails. И мы хотели бы продать всю систему в течение следующего года или около того для использования другими компаниями.

В настоящее время у нас есть только я как программист, но я не считаю, что этого достаточно. Есть ли у кого-нибудь рекомендации относительно того, сколько программистов должен иметь проект такого масштаба или как мы должны определить ответ на этот вопрос? Особенно учитывая тот факт, что руководство хотело бы, чтобы продукт стал коммерческим качеством к следующему году?


11
Я ждал шутки с лампочкой :(
Одед

лол ... погуглите заголовок, и вы, вероятно, найдете его. Когда я гуглил, я действительно нашел кучу этих случайно LOL.
kstevens715

8
Если требования продолжат изменяться, никакое количество дополнительных рук не доставит этот продукт и не выйдет за его пределы. Вы должны закрепить требования в первую очередь.
Одд

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

Этот вопрос кажется очень похожим на этот вопрос . Возможно, вы также найдете некоторые ответы там полезными.
С.Робинс

Ответы:


3

Я бы сказал как минимум 5 человек. Один для тестирования, один для спецификации, поддержки и документации и 3devs. В вашем случае есть много вещей, которые нужно протестировать, поэтому 50% выделенный тестер не должен быть необоснованным. Должен быть человек, записывающий требования и имеющий поддержку клиентов, настраивающий вашу инфраструктуру для тестирования и т. Д. Я считаю, что для такого проекта не хватает трех разработчиков. Большой бэкэнд, который интегрирован во многие сторонние системы, и полный набор с огромным количеством настраиваемых отчетов. Я бы хотел.

  1. Хороший бэкэнд-разработчик (постоянство / бизнес-уровень)
  2. Хороший средний / внешний разработчик, создающий классы действий и JavaScript CSS Design.
  3. Хороший разработчик, действующий архитектор, но также создающий код на всех уровнях с помощью экспертов от двух других. Этот разработчик также может делать такие вещи, как настройка фреймворка JUnit, Maven Jenkins Git ветвление и так далее.

Что произойдет, если вы уйдете, заболеете, уйдете в отпуск и т. Д. Один человек на проект никогда не бывает умным. Также не хорошо быть одному, так как вы не профессионально развиваетесь без коллег. Я работаю довольно часто один, создавая новые архитектуры и так далее, часто в командах, скажем, из 5 разработчиков, но я никогда не развиваюсь так сильно, как когда я говорю коллеге, давайте настроим это вместе, и мы запираемся на неделю, разговаривая, обсуждая и выбор рамок. Парное программирование чрезвычайно полезно и не может быть выполнено одним разработчиком, и кто будет делать обзоры кода, если вы не уверены? Если вы застряли, кто вам поможет? Я бы предпринял проект только на одного человека, если бы он был частью более широкой области и мог бы привлечь экспертные ресурсы, если это необходимо.


1
Прошлым летом я взял двухдневный отпуск, и кому-то пришлось ворваться в мой дом, чтобы взять мой ноутбук ... да. Я всегда говорю о работе в вакууме, потому что у меня нет многих других разработчиков, с которыми можно взаимодействовать. И живя в маленьком городе, нет даже групп пользователей или чего-либо, к чему можно присоединиться. Мы (я?) Недавно начали писать тестовый код, фактически, когда мы начали переходить на Rails. Я уже не представляю разработку без тестов. Мне нравится идея иметь 50% преданного тестера.
kstevens715

1
По крайней мере один разработчик должен быть специалистом по базам данных.
HLGEM

8

Добро пожаловать в трудный мир ресурсов !

Проблема заключается не в размере проекта против размера команды. Это очень распространенное заблуждение, которое часто скрывает другие проблемы, которые обычно связаны с управлением. Все дело в сфере . Вам нужно решить, чего вы можете достичь с помощью имеющихся у вас ресурсов - иначе вас. Затем вам нужно решить, достаточна ли ваша способность справляться с рабочей нагрузкой, чтобы справиться с задачей в течение выделенных вами временных периодов. Таким образом, потребности вашего проекта должны быть определены и определены.

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

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

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


Казалось бы, цель - полное переписывание системы 250K SLOC во что-то, что имеет качество термоусадочной пленки (или, по крайней мере, качество программного обеспечения). Преимущество состоит в том, что сбор требований и общий дизайн, вероятно, уже выполнены. Это не мало, и не то, что для одного разработчика, который имеет другие обязанности.
Дэвид Торнли

@DavidThornley Это в значительной степени зависит от объема обязанностей разработчика, его сроков, его рабочей нагрузки, того, как его компания уже продвигает продукт. Я видел много сложных проектов, над которыми работала команда из 1-2 человек, которые были очень успешными, потому что ими хорошо управляли ... и многие другие, которые потерпели неудачу. Однако я согласен с тем, что эта задача является большой и сама по себе является чем-то вроде красного флага в плане предоставления ресурсов. Дело в том, что не стоит просто нанимать много людей, не выполнив сначала небольшую домашнюю работу, и в этом смысл моего ответа. :-)
С.Робинс

«Сфера» - это то, о чем я рассказывал в последние пару месяцев. 20% проекта оказывает 80% влияния на компанию. Это то, на чем я пытаюсь сосредоточиться. К сожалению, 80%, на которые приходится 20% воздействия, - это то, что выдвигается на передний план, когда мы пытаемся справляться с «чрезвычайными ситуациями», добавляя больше кода и функций. Однажды я попросил заморозить функцию, чтобы исправить некоторые основные проблемы. Они дали мне 5 дней. Само собой разумеется, что это 5 лет спустя, и многие из основных проблем остаются. Спасибо за ваш пост, хотя, очень полезно.
kstevens715

6

Успех продукта / проекта будет зависеть от приверженности компании, которая за него платит. Если они собираются нанимать больше программистов / вспомогательного персонала, это приведет к снижению производительности труда одного программиста, который знает, что должен обучать, учить, управлять и т. Д. Не то, чтобы это было плохо ... но будет должно быть снижение до того, как будет реализовано любое увеличение. Также есть необходимость в бизнес-аналитиках, менеджерах, отделах продаж и поддержке продукта, как только он поступит в продажу.

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

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

ты сейчас работаешь мозгами? Если это так, будьте готовы работать вдвое усерднее, если ожидаете, что справитесь с этим процессом и продолжите развиваться (повысить должное?)

и вот ответ из моего предыдущего опыта, когда я находился в аналогичной ситуации с ценами в Южной Калифорнии:

5-6 человек && ~ 500k

  • 1 ведущий разработчик / менеджер, носящий все шляпы (~ 100k - 120k)

  • 2 старших (очень способных, самостоятельных) программиста с хорошим пониманием БД и навыками (2x ~ 80 - 100k)

  • 1 Менеджер проекта для взаимодействия с менеджментом ($$?). Этот человек также должен понимать потребности приложения и сообщать о них непосредственно программистам.

  • 1? (HTML / UI) разработчик? с навыками JavaScript (я ненавижу программирование пользовательского интерфейса / код разметки)

  • 1? База данных человека? однако, у большинства хороших программистов нет проблем с созданием масштабируемых структур данных, однако, если вы собираетесь заниматься вопросами оптимизации, вам, по крайней мере, понадобится консультант


1
+1 Мне очень нравится твоя поломка! Завершите OT зарплаты, которые вы цитируете, для меня огорчительно, так как я думал о работе в SoCal, но они не намного выше, чем в Западной Европе, если люди старшего возраста работают как MSc + 5 лет.
Farmor

1
Я согласен, за исключением того, что я бы также рекомендовал программисту начального уровня взять на себя обязанности поддержки (настройка клиента и незначительные улучшения) и выполнять общую работу. Комбинирование некоторых ролей может работать в зависимости от уровня квалификации.
jfrankcarr

Вау, вы можете получить старших разработчиков в So Cal за 80-100K? Это кажется довольно низким, учитывая стоимость жизни. Возможно, у нас разные представления о «старшем»; старшие разработчики, которых я знаю в Далласе, получают значительно больше.
Кевин Клайн

Вероятно, у нас тоже есть разные представления о том, какой вкус хороший. Я нанял 2 .Net Sr., которые были молоды и талантливы с большим опытом за последние 10 лет, которые были готовы работать в этом диапазоне. Мы использовали последнюю версию Microsoft Stack (TFS, .NET 4, C #, EF 4.1, MSSQL 2008 R2, бла-бла…), и у нас не было проблем с созданием хорошего чистого кода. Мы были маленькой командой, и проблема, которую мы обнаружили, пытаясь нанять некоторых старших, заключалась в том, что они были невосприимчивы к обучению, имели слишком много мнений и имели слишком много багажа (у нас тоже не было большого окна для найма)
Hanzolo

2

1 программист на большой кодовом со всей ответственностью настройки, тестирования, общения, поддержки, документирования и фиксация ошибки не будет много времени для написания нового кода или добавлять новые функции (или даже рефакторинг старого кода).

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

У больших проектов есть определенное количество связанных накладных расходов, которые не исчезнут (особенно если внедряете / тестируете с новыми клиентами все время, как вам кажется). По этой причине у вас есть поддержка ротаций и поддержка в целом; поэтому некоторые из членов команды имеют время для работы над новыми функциями.

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


95% моего времени уходит на выполнение одной из этих задач. Мне нравится идея поддержки поворотов. Это может быть что-то, чтобы рассмотреть, если мы нанимаем кого-то, кого я могу вращаться с лол. Сегодня, например, я действительно начал работать над некоторым основным кодом и был прерван, потому что кто-то нуждался в батарее.
kstevens715

@ kstevens715 - Похоже, вам нужна помощь, даже если это чей-то технический ребенок. Я предполагаю, что вам платят по крайней мере пятизначный доход, если бы мне сказали, чтобы я получил батарею, это будет стоить около 10 долларов для моего сотрудника (35% от моей почасовой заработной платы).
Ramhound
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.