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

Постановка задач

• Нужен таск-трекер, лучше old good redmine или что-нибудь похожее. Agile-штуки вроде Pivotal или Trello хорошо работают только при поддержке agile менеджментом - маленькие задачи, короткие итерации. Если же задача требует обсуждения и уточнения - такие трекеры начинают мешать.
• Нужен product owner, как его ни назови. Человек (или коллективный орган), который точно знает, как будет выглядеть и работать продукт. Он должен уметь понимать языки и пользователя, и разработчика, и бегло переводить с одного на другой. Если такого нет - нужно его нанять или назначить.

Сервер

• Хостинг. Нужно иметь минимум 2 инстанса продукта - для разработки/тестирования и для выкатки на публику.
• Нужно бэкапить как минимум продакшен, как минимум раз в неделю. Лучше раз в день. И бэкапы хранить отдельно от рабочего сервера (например, в Amazon S3).
• Нужно иметь хранилище кода с контролем версий. Я считаю, что лучше всего для этого подходит аккаунт на github/bitbucket (в первую очередь, из-за удобного просмотра и возможности быстро показать коллегам код), в случае обострения паранойи можно держать репозиторий и на своем сервере.

Дизайн

• Дизайнер должен быть доступен всегда. Практически всегда нужно вносить какие-то мелкие правки или добавлять элементы интерфейса. Лучше, чтобы этим занимался один человек.
• Дизайнер должен разбираться в проектировании интерфейсов (практически тавтология, да). В Рунете часто считается, даже на больших проектах, что дизайнер рисует всякие красивости, а кнопочки и формы программисты сами раскидают. Мы, конечно, раскидаем, только результат чаще всего будет неудобен и непонятен органическим гуманоидным формам жизни.
• Дизайн должен учитывать работу с сервисом с мобильных девайсов. Хотя бы начиная с андроидного среднего разрешения 800х480 и с тач-скрином.
• И вообще, дизайнер должен осознавать, как его картинки будут верстаться и работать.

Верстка

• Вопрос “дивы или таблицы” давно не стоит. Естественно, на дивах, хорошо бы - семантичная, еще лучше - на фреймворке типа bootstrap.
• Если дизайнерские выкрутасы нельзя сверстать аккуратно - стоит попросить дизайнера переделать (если это не принципиальный элемент). Поддержка выйдет дороже.
• В верстке должны быть все возможные состояния элементов. Если это кнопка - она должна быть в нажатом и отключенном состоянии, если форма - должны быть сверстаны поля с ошибками.
• Я выше написал про поддержку мобильных платформ - к верстке это тем более относится.
• Идеально, если верстальщик умеет поднять у себя проект и пользоваться репозиторием кода.

Бэкенд

• Код должен следовать гайдлайнам языка и фреймворка. Если он писался человеком без опыта работы с конкретной платформой - код смотрим особо тщательно, будь автор хоть суперкрутой программер. Больше того, “суперкрутые”, даже чаще используют мозгодробительные конструкции, в которых никто потом не может разобраться.
• Должна быть документация. Коментарии в коде, тесты, отдельная документация - уже не так важно, что именно. Ведущего разработчика или owner-а всегда может переехать трамвай, и нужно быть уверенным, что проект после этого не развалится, как карточный домик.
• Обязательно должен быть поставлен процесс тестирования. Опять же, конкретные методики это та еще пища для холивара, но что-то быть должно. Иначе к запуску окажется, что все ломается, никто не знает точно, работает фича или нет, а если не работает - кто и когда ее сломал.

Коммуникации

Все члены команды должны быть связаны со всеми остальными. Давно уже у всех есть доступ в интернет, есть Skype, есть TeamViewer (if you like it - buy it!). Сотрудник, который проверяет почту раз в неделю, а отвечает на нее еще реже (при этом, сотового у него нет, потому что он Перельман) - не очень хороший сотрудник (хоть и, возможно, отличный программист). Схема, при которой все общение между верстальщиками, программистами и дизайнерами идет только через менеджера - тоже не очень эффективна. Имеет смысл ограничить “прямую” постановку задач, но вопросы типа “как вот это у тебя должно работать” должны ходить напрямую.

Мы не успеваем!!!

Если проект не укладывается в сроки или в бюджет - команда об этом должна узнать как можно раньше. Чтобы вместо “релиза” глючного, постоянно падающего и частично вообще нефункционального нечта можно было заранее обсудить сроки, урезать функциональность (почти всегда оказывается, что можно урезать что-то ресурсоемкое, но маловажное для пользователя) и выкатить рабочий продукт.

Собственно, это одна из мантр agile - постоянно иметь рабочий продукт. После первой недельной итерации мы должны иметь рабочий продукт. Да, он мало что умеет, но он работает, он не падает, и его всегда можно показать при возникновении вопроса “а чем вы тут так долго занимаетесь?”.

Методология

Лучшая методология разработки ПО

А если человек много треплется, но мало двигает дело вперед - ну его нафиг.

У нас не сработает

Если в команде мало людей (нет денег, злой заказчик и т.п.), указанные выше роли можно распределять по нескольку на одного человека. От чего-то можно отказаться совсем (например, не делать графический дизайн, а взять готовую тему для фреймворка, или вместо найма программистов взять cms), важно только осознавать “за” и “против”.