Начнем с найма хорошей команды подходящих профессионалов для вашего проекта. В типичном бизнес-приложении вам нужно как минимум нанять разработчика базы данных и администратора базы данных, специалиста по обеспечению качества, системного администратора, бизнес-аналитиков, разработчиков приложений, специалиста по пользовательскому интерфейсу и руководителей команд. DBA, системный администратор, бизнес-аналитики и QA должны находиться в отдельной цепочке отчетности от команды разработчиков. Специалист по разработке баз данных должен подчиняться тому же техническому руководителю, что и разработчики приложений и специалист по пользовательскому интерфейсу.
Настройте офисное пространство. Частные офисы хороши, если вы можете их получить (я желаю вам удачи в этом), но как минимум вам нужны столы, телефоны, компьютеры, доски и пара выделенных конференц-залов. Убедитесь, что есть место для перерывов на обед, холодильник, безалкогольные напитки, закуски и кофе. Бесплатные безалкогольные напитки и кофе еще лучше.
Настройте серверы dev / qa / staging и prod для приложения и баз данных. Базы данных никогда не должны находиться на одном сервере с приложениями. В зависимости от размера и масштаба проекта вам может потребоваться несколько серверов или сетей SAN и т. Д. Для каждой среды.
Как только серверы настроены, запланируйте резервное копирование файловой системы, базы данных и журналов транзакций базы данных. Сделайте это в самый первый день, когда все готово. Нанимайте такую фирму, как Iron Mountain, для еженедельного резервного копирования.
Настройте систему контроля версий и создайте документ, описывающий, как она будет использоваться. Не забывайте настаивать на том, чтобы ВСЕ структурные изменения базы данных и вставки данных для таблиц типов поиска были в сценариях контроля версий. Это облегчит развертывание.
Купите коммерческое программное обеспечение или загрузите программное обеспечение с открытым исходным кодом для набора инструментов, который вы решили использовать с лицензиями для всех соответствующих пользователей.
Купите машины разработчика, которые кричат быстро и имеют два монитора. Купите хотя бы один тестовый пользовательский компьютер, который стонет медленно и типично для того, что пользователи будут иметь на своих рабочих столах.
Обучите своих новых разработчиков тому, как вы хотите, чтобы все было сделано. Если у вас достаточно большая команда, чтобы иметь несколько начинающих разработчиков, запланируйте для них дополнительное обучение и включите время в планирование своего проекта. Очень внимательно следите за юниорами в течение как минимум трех месяцев. Следите за всеми новыми сотрудниками внимательно в течение первого месяца. Избавьтесь от мертвой древесины и мошеннических разработчиков как можно скорее.
Определите, что нужно сделать в каком порядке (критический путь). Не назначайте задачи в конце критического пути, пока задачи, от которых они зависят, не будут выполнены.
Создание планов испытаний и требований.
Организуйте регулярные запланированные встречи с клиентами. Они заслуживают того, чтобы знать, что вы делаете, и каковы препятствия. Не забудьте сказать им, когда будет поздно. Если у вас три недели до крайнего срока, и вы уже знаете, что пропустите его, этот дефицит не исчезнет волшебным образом, пока вы не сообщите об этом клиенту. Убедитесь, что клиент знает, что добавленные требования означают добавленные затраты и время и что при каждом добавленном требовании должны быть либо отменены другие задачи, либо конечный срок изменится на количество часов в новых задачах. Если вы сделаете это с самого начала, это сэкономит вам массу времени и времени, а также приведет к перерасходу средств вашей группы, а не клиента.
Настройте среду для тестирования производительности, а не только скорость одного пользователя, но такую, где вы можете протестировать ожидаемое количество одновременных пользователей. Не ждите, чтобы сделать это тестирование до дня, прежде чем вы начнете жить.
При планировании проекта предположим, что QA найдет ошибки и что на их устранение потребуется время. Не планируйте QA только на один день в конце.
Создайте тестовые данные примерно того размера, который, по вашему мнению, будет иметь базу данных. Заставьте всех разработчиков проверить свой код на базе данных такого размера. Не позволяйте разработчикам разрабатывать только против небольшой базы данных на своих персональных компьютерах. Это частая причина того, что код работает нормально, пока не попадет в производство.
Планируйте вознаграждения в бюджет. Это демотивирует людей, когда они отрабатывают свои задницы в течение нескольких месяцев, и только менеджеры получают бонусы. Также говорите спасибо часто и письменно.
Вам может понадобиться система управления проектами или, по крайней мере, настроить электронные таблицы для отслеживания того, что вам нужно отслеживать. При планировании проекта принимайте в свой план не более шести часов в день человека. Это помогает учесть время, которое будет потрачено не на проект, например, отпуск, больничное время, праздники, встречи с персоналом, обзоры эффективности и т. Д. Если вы знаете, что проект находится в периоде высокой недоступности (например, проект, который выполняется с 1 ноября по 1 января в США), возможно, вам придется сделать дополнительные надбавки для большего отпуска и отдыха. Несправедливо ожидать, что разработчики откажутся от своих отпусков и отпусков, и никто не может предсказать, когда произойдут такие вещи, как больничный, присяжные, тяжелая утрата и т.д. Предположим, они произойдут с вашей командой в этом проекте.