Как сократить время реализации проекта?

Делаем проект на PHP. Допустим этот проект будет делать наш программист 120 дней.
Нужен человек, который сможет решить/помочь решить/или проконсультировать нас так, чтобы мы этот проект реализовали за 20-30 дней.

Расписали проект по версиями, от версии 0.1 до версии 0.8.

Проблема в том, что мы абсолютно не понимаем, как распределить это всё, чтобы этот проект делали несколько программистов, а один наш программист до 0.8 версии будет доводить дней 120.

Как сократить время реализации проекта до 30 дней, что в таком случае делают опытные программисты\руководители?

Наймите аналитика

lev4852,

Кто такой аналитик? Что он должен делать?

Цитата ("bridgid2009"):

Как сократить время реализации проекта до 30 дней, что в таком случае делают опытные программисты\руководители?

Вариантов решения много:

- почему Вам нужно делать сложный проект за месяц? Спешка не приводит ни к чему хорошему. Продукт, сделанный в спешке, содержит много ошибок, не отлажен и не закончен.
Пересмотреть сроки. Лучше взять срок с запасом и сделать качественно.
- нанять бригаду программистов, распределить между ними, кто какую работу будет делать.
- упростить Ваш функционал (убрать не нужные модули и оставить только самые важные)
- взять за основу готовое решение, которое содержит многое из того, что Вам нужно, остальное доработать

Цитата ("bridgid2009"):

Кто такой аналитик? Что он должен делать?

ссылка

Цитата ("bridgid2009"):

Как сократить время реализации проекта до 30 дней, что в таком случае делают опытные программисты\руководители?

Опытные руководители не берутся делать работу, которая занимает много месяцев, за 1 месяц.

Цитата ("superkoder"):

Опытные руководители не берутся делать работу, которая занимает много месяцев, за 1 месяц.

Просто этот проект делает единственный адекватный PHP программист которого мы нашли...но времени у него на этот проект немного, до 4 часов в день.

Цитата ("bridgid2009"):

Просто этот проект делает единственный адекватный PHP программист которого мы нашли...но времени у него на этот проект немного, до 4 часов в день.

Значит Вы не рассчитали свои силы. Ваши возможности позволяют реализовать проект за много месяцев,
а Вы взялись за 1 месяц.
Пересмотрите сроки.

Цитата ("superkoder"):

Опытные руководители не берутся делать работу, которая занимает много месяцев, за 1 месяц.

Опытные руководители возможно этот проект оценили бы в 2 недели...

Цитата ("bridgid2009"):

Опытные руководители возможно этот проект оценили бы в 2 недели...

Тогда почему у Вас до сих пор сложности с реализацией? Если, как Вы говорите, работы на 2 недели?
В чём тогда вопрос?

Сначала система проектируется. И потом уже оцениваются временные затраты. А не наоборот...

Цитата ("incweb"):

Сначала система проектируется. И потом уже оцениваются временные затраты. А не наоборот...

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

superkoder, да,бывает... сделать за месяц, потом три раза по три месяца прикручивать разные костыли.... и т.д.

Цитата ("bridgid2009"):

Допустим этот проект будет делать наш программист 120 дней.

Цитата ("bridgid2009"):

Как сократить время реализации проекта до 30 дней, что в таком случае делают опытные программисты\руководители?

Цитата ("bridgid2009"):

Просто этот проект делает единственный адекватный PHP программист которого мы нашли...но времени у него на этот проект немного, до 4 часов в день.

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

Вернитесь снова на этап проектирования, постановки задачи и оценки сроков, и сделайте на этот раз всё грамотно, передоговоритесь с заказчиком.

Ух, прям как у меня проблема. Интересно, а откуда взялась цифра в 120 дней?
Если её оценивал ваш программист, то тут есть два варианта:
1. Он расписал проект по пунктам, разбил на небольшие подзадачи, прикинул выходные/болезни/цунами/революцию, умножил срок на два и получил 120 дней. Значит он смело может называться руководителем проекта, уже может ответить вам на ваш вопрос по ускорению и сделать всё в наилучшем виде за 29 дней.
2. Он прикинул "в уме" и 90% что промахнулся минимум вдвое. Это не с потолка, это грустная статистика

Предположим, найдёте консультанта.
Ему самому понадобится минимум неделя на то, чтоб въехать в задачу и накидать план реализации.
А потом начнётся самое весёлое - поиск исполнителей. Наверно, всё зависит от финансовых возможностей, но я уже больше месяца ищу хорошего php-программиста на 80человеко-часов в месяц с окладом в 500-600$
По ходу кризис кончился, все заняты

Цитата ("superkoder"):

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

Вернитесь снова на этап проектирования, постановки задачи и оценки сроков, и сделайте на этот раз всё грамотно, передоговоритесь с заказчиком.

Хорошо, а как сделать так, чтобы проект который можно сделать за 30 дней сделать в срок, а не как обычно...как найти адекватных программистов и реализовать их работу над одним проектом?

Цитата ("bridgid2009"):

а как сделать так, чтобы проект который можно сделать за 30 дней сделать в срок, а не как обычно...

Никак. Это фантастика.
Если программист оценил работу в месяц, то руководитель проекта должен оценить работу в 3 месяца.
Тогда задержка проекта будет всего пару недель.

Цитата ("bridgid2009"):

как найти адекватных программистов

Это вопрос Вашего везения и бюджета.
Развивайте везение. А оно тренируется, есть методики.

Цитата ("bridgid2009"):

реализовать их работу над одним проектом

Разбить проект на части и пусть каждый делает свою часть работы.

Я вот сам программист, работал часто в больших коммандах, в общем ситуация такая:
Вначале все оценивается шарящим (это обязательно!!! Потому как работал и с нешарящим...) руководством, на это обычно уходило около 1-ой недели, затем все передается тимлиду, у которого в подчинении команда, он раздает задачи с учетом отсутствия коллизий в плане необходимости менять одно и тоже, дает примерное время на выполнение.
Оно примерное потому что никогда ты точно не скажешь, даже сам сколько будешь это делать. Я вот могу сказать, что выведу информацию о ПХП за 5 минут Много просто возникает чего по мере реализации...

По сути руководство нафиг не нужно, сам тимлид может все оценить, а также он и может помогать над проектом.

Ко всем ориентировочным срокам добавляется 30-50%, а также ~30% на отладку на хьюман-тест данных.
Можно юзать всякие тесты, но я, например, просматриваю очень внимательно код, где сомневаюсь - проверяю. Хотя изначально пишу практически без ошибок, просто превычка хорошая везде следить за типом данных и переменными, всякими там инъекциями.

Также очень важно вести разработку именно на той платформе, на которой будет все работать, если это ПХП проект НИ В КОЕМ СЛУЧАЕ на винде (если, конечно, ПХП не будет работать на ИИС, например). Есть просто отличия и довольно-таки серъезные в ПХП нормальном и виндовом...

Это я так немного сказал

Цитата ("bridgid2009"):

Проблема в том, что мы абсолютно не понимаем, как распределить это всё, чтобы этот проект делали несколько программистов, а один наш программист до 0.8 версии будет доводить дней 120.
Как сократить время реализации проекта до 30 дней, что в таком случае делают опытные программисты\руководители?

Капитан Очевидность подсказывает: если Вы не понимаете, как разделить проект на части, и как распараллелить работу, то наймите того, кто понимает.

Можете и сами попробовать. Что нужно:

1. Бизнес-аналитика. Соберите все требования к проекту, включая низкоуровневые. Сгруппируйте требования по функциональным модулям (например в случае с сайтом — требования для админки, требования для форума, требования для баннерокрутилки, требования для реферальной системы и т.д.).

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

3. Подбор кадров. Отберите самых матерых спецов, что есть в наличии и на которых есть деньги. Под них потом будете делать оценку объема работ и сроков (а не рассчитывая на "среднего программиста", как многие начинающие делают). Ламеров гоните подальше, они будут только мешать и отвлекать спецов.

4. Планирование сроков и объемов работ. Тут отдельно оцените каждый модуль, каждый функциональный элемент. Добавьте время на синхронизацию работ и менеджмент, выделите время на тестирование, на перекресный ревьюинг кода, не забудьте про документирование, и т.д. Конечно, сроки должны быть с запасом. Особо внимательно отнеситесь к той функциональности, с которой еще не сталкивались, и которую нужно будет исследовать. Это нужно будет особо отметить в риск листе (см. ниже).

5. Распределение работы. Соберите информацию обо всех ресурсах, что у вас имеются. В данном случае ресурсы — это прежде всего люди, они разные, разного уровня, разной специализации и квалификации, имеют в наличие различное количество времени и т.д. Распределите их по подсистемам и модулям так, чтобы каждый из них использовался оптимально. Это, конечно, целая наука... поначалу можете это делать интуитивно, потом в дальнейшем, по мере накопления опыта и освоения методик, по науке будете делать. Диаграммы Ганта тут подойдут в самый раз.

6. Риск менеджмент. Заведите так называемый риск-лист. Туда вносите все риски, связанные с проектом. Ищите пути для минимизации каждого риска, назначайте ответственного за минимизацию каждого риска в списке. "Заказчик задержит оплату", "Дизайнер Вася уйдет в запой", "В офисе выключат электричество" — все это, конечно, тоже можно вносить в этот список (это для продвинутых уже), но вообще для начала можно хотя бы учитывать технические риски по тем или иным проектным решениям. Цель — быть готовым к любым неожиданностям, которые помешают команде сделать проект качественно и в срок.

7. Проектный менеджмент. Цель — контроль и учет того, что происходит в проекте, и принятие решений соответственно этому во благо проекта. Организуйте работу спецов, и требуйте ежедневной отчетности. Желательно не слишком навязчиво. Если в проекте все идет гладко, то достаточно в конце дня лиду просматривать исходники в SVN и подергать последний билд. Если не гладко, то в зависимости от ситуации перераспределять нагрузку, подключать еще ресурсы, и т.д. (см. про риск менеджмент).

8. Организация процесса разработки. Это важнейшее дело. Организовать процесс разработки так, чтобы все было как по маслу. Чтобы все были на своем месте, проблемы или не возникали вообще, или быстро решались. Тут и документооборот, и непрерывная сборка, и тесты, и система контроля версий с бранчами (если нужно), и внутренние блоги разработчиков, и отчеты... Цель — упорядочить все что делается в команде в рамках проекта, держать под контролем.

9. Подключение стороннего эксперта. Заведите эксперта со стороны, который будет периодически, наприемр пару раз в неделю раза в неделю, ревьюить все что делается в проекте. К разработчикам его пускать напрямую не обязательно, достаточно его пустить в SVN и общаться с ним на уровне отчетов. Подключить его лучше еще на этапе проектирования. Цель — повышение качества проекта и устранение большинства технических рисков. На порядок повышается вероятность, что ламерство будет обнаружено и исправлено сразу, а не за 2 дня до сдачи проекта.

10. Тимбилдинг. Это если работаете в одном офисе. К этому нужно подойти с фантазией, наиболее распространено — бильярд и банька, но есть и футбол, велосипеды, и т.д. Если работаете удаленно, и есть общие интересы, то тоже можно (некоторые в шахматы после работы рубятся по паре часов, или в РПГ всякие), но это уже сложнее. Цель этого действа — сплотить команду, увеличить степень интеграции, коммуникации, и т.д. И это реально работает.

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