Как вы узнаете, сколько программистов для успеха конкретного проекта?
Компания, в которой я работаю, выполняет заказы для компаний-клиентов. Мы разработали собственную систему управления складом, которая занимается управлением запасами на основе местоположения, обработкой заказов, формированием накладных, выставлением счетов, аудитом грузов и отчетами (вероятно, 50 отчетов). Он также имеет функции сканирования штрих-кода и клиентский портал, а также десятки других небольших функций. Он также включает в себя полное время сотрудника. Он интегрируется с Quickbooks, UPS и FedEx. Он обрабатывает работу как минимум для 50 клиентов, каждый из которых немного отличается по своей функциональности. Например, мы импортируем заказы из файлов, которые отправляют клиенты, но каждый клиент отправляет свой формат файла (csv, excel, flat file и веб-сервисы), поэтому у нас есть более десятка настроек методов преобразования заказов. Экспорт это та же история.
Проект сложен и растет с каждым днем: более четверти миллиона строк кода. Это около 250 000 строк кода VB.NET, 6200 строк кода Ruby и, возможно, 5000 строк PHP. Он также имеет базу данных MySQL с около 200 таблицами.
Из-за постоянно меняющихся требований и различных потребностей десятков клиентов сам код значительно отличается по качеству от крайне плохого до относительно хорошего кода.
В настоящее время в этом проекте есть только один программист - я сам. Я также в настоящее время делаю всю поддержку продукта для нашей компании приблизительно 75 человек. Это включает устранение неполадок и настройку новых клиентов, а также любые новые необходимые функции. Кроме того, мы пытаемся переписать все это на 100% на основе Ruby on Rails. И мы хотели бы продать всю систему в течение следующего года или около того для использования другими компаниями.
В настоящее время у нас есть только я как программист, но я не считаю, что этого достаточно. Есть ли у кого-нибудь рекомендации относительно того, сколько программистов должен иметь проект такого масштаба или как мы должны определить ответ на этот вопрос? Особенно учитывая тот факт, что руководство хотело бы, чтобы продукт стал коммерческим качеством к следующему году?
источник
Ответы:
Я бы сказал как минимум 5 человек. Один для тестирования, один для спецификации, поддержки и документации и 3devs. В вашем случае есть много вещей, которые нужно протестировать, поэтому 50% выделенный тестер не должен быть необоснованным. Должен быть человек, записывающий требования и имеющий поддержку клиентов, настраивающий вашу инфраструктуру для тестирования и т. Д. Я считаю, что для такого проекта не хватает трех разработчиков. Большой бэкэнд, который интегрирован во многие сторонние системы, и полный набор с огромным количеством настраиваемых отчетов. Я бы хотел.
Что произойдет, если вы уйдете, заболеете, уйдете в отпуск и т. Д. Один человек на проект никогда не бывает умным. Также не хорошо быть одному, так как вы не профессионально развиваетесь без коллег. Я работаю довольно часто один, создавая новые архитектуры и так далее, часто в командах, скажем, из 5 разработчиков, но я никогда не развиваюсь так сильно, как когда я говорю коллеге, давайте настроим это вместе, и мы запираемся на неделю, разговаривая, обсуждая и выбор рамок. Парное программирование чрезвычайно полезно и не может быть выполнено одним разработчиком, и кто будет делать обзоры кода, если вы не уверены? Если вы застряли, кто вам поможет? Я бы предпринял проект только на одного человека, если бы он был частью более широкой области и мог бы привлечь экспертные ресурсы, если это необходимо.
источник
Добро пожаловать в трудный мир ресурсов !
Проблема заключается не в размере проекта против размера команды. Это очень распространенное заблуждение, которое часто скрывает другие проблемы, которые обычно связаны с управлением. Все дело в сфере . Вам нужно решить, чего вы можете достичь с помощью имеющихся у вас ресурсов - иначе вас. Затем вам нужно решить, достаточна ли ваша способность справляться с рабочей нагрузкой, чтобы справиться с задачей в течение выделенных вами временных периодов. Таким образом, потребности вашего проекта должны быть определены и определены.
Когда у вас есть представление о масштабах ваших требований, вы можете легче определить рабочую нагрузку, необходимую для достижения результата в течение определенного периода времени. Если ваши ресурсы могут быть перегружены, вам потребуется больше персонала. Если ваши ресурсы могут быть недостаточно использованы, то вы можете оказаться в состоянии либо приблизить свой срок, либо увеличить масштаб вашего проекта.
Если ваш инстинкт инстинкта подсказывает вам, что у вас недостаточно персонала для управления проектом, вы можете быть правы, но вам нужно понять, почему это так. Недостаточно просто иметь чувство. Вместо этого вы должны быть в состоянии исследовать проблему с научной точки зрения, чтобы предоставить доказательства, подтверждающие ваши инстинкты, и вы должны быть готовы столкнуться с возможностью того, что ваши инстинкты могут даже ошибаться. После того, как вы собрали доказательства - то есть: охватили проект, вам действительно нужно сесть за стол с руководством и обосновать необходимость сокращения масштабов проекта или увеличения доступных ресурсов для обеспечения успеха проекта на основе на доказательствах под рукой.
источник
Успех продукта / проекта будет зависеть от приверженности компании, которая за него платит. Если они собираются нанимать больше программистов / вспомогательного персонала, это приведет к снижению производительности труда одного программиста, который знает, что должен обучать, учить, управлять и т. Д. Не то, чтобы это было плохо ... но будет должно быть снижение до того, как будет реализовано любое увеличение. Также есть необходимость в бизнес-аналитиках, менеджерах, отделах продаж и поддержке продукта, как только он поступит в продажу.
Размещение коммерческого приложения - это гораздо больше, чем просто создание надежной платформы. есть требования к поддержке, техническая поддержка, исправление ошибок, обучение пользователей и т. д.
у вас есть какая-нибудь хорошая процедура анализа / спецификации / оценки? если нет, начните сейчас , вы можете сделать это самостоятельно.
ты сейчас работаешь мозгами? Если это так, будьте готовы работать вдвое усерднее, если ожидаете, что справитесь с этим процессом и продолжите развиваться (повысить должное?)
и вот ответ из моего предыдущего опыта, когда я находился в аналогичной ситуации с ценами в Южной Калифорнии:
5-6 человек && ~ 500k
1 ведущий разработчик / менеджер, носящий все шляпы (~ 100k - 120k)
2 старших (очень способных, самостоятельных) программиста с хорошим пониманием БД и навыками (2x ~ 80 - 100k)
1 Менеджер проекта для взаимодействия с менеджментом ($$?). Этот человек также должен понимать потребности приложения и сообщать о них непосредственно программистам.
1? (HTML / UI) разработчик? с навыками JavaScript (я ненавижу программирование пользовательского интерфейса / код разметки)
1? База данных человека? однако, у большинства хороших программистов нет проблем с созданием масштабируемых структур данных, однако, если вы собираетесь заниматься вопросами оптимизации, вам, по крайней мере, понадобится консультант
источник
1 программист на большой кодовом со всей ответственностью настройки, тестирования, общения, поддержки, документирования и фиксация ошибки не будет много времени для написания нового кода или добавлять новые функции (или даже рефакторинг старого кода).
Разбейте свою неделю на процент этих обязательных задач, которые не расширяют бизнес, и вы будете удивлены тем, насколько быстро руководство обращается за дополнительной помощью.
У больших проектов есть определенное количество связанных накладных расходов, которые не исчезнут (особенно если внедряете / тестируете с новыми клиентами все время, как вам кажется). По этой причине у вас есть поддержка ротаций и поддержка в целом; поэтому некоторые из членов команды имеют время для работы над новыми функциями.
Вы также можете заглянуть в книги по оценке программного обеспечения. Эти книги могут показаться не такими интересными, но они содержат интересные примеры из разных областей и подтверждают их заявления.
источник