Все, вероятно, слышали про легендарный Joel Test, который упрощенно показывает степень зрелости процессов разработки IT-проектов. Тем, кто про него не слышал - рекомендую обратиться к первоисточнику на Сайте Джоеля.

Ок, это замечательный тест, мне лично он очень нравится.
Но некоторые пункты в нем не совсем понятны, или же допускают двоякое толкование.
Хочу предложить вам свою вольную интерпретацию теста Джоеля, адаптированную для разработки веб-проектов в украинских реалиях (основываясь на личном опыте, разумеется). Я также попытался сделать предположения о том, к чему приводит низкая оценка по каждому из пунктов.
Все нижесказанное имеет субъективный характер, и не претендует на истинность.

1. Do you use source control?
(Используете ли вы систему контроля версий?)
Интересен не только факт наличия системы контроля версий, но и методика ее использования. Предположу примерно такую шкалу зрелости в этом вопросе:
1.1 Система контроля версий есть.
1.2 У каждого разработчика есть своя версия кода, которая появляется из транка, в транк же и вливается.
1.3 У каждого проекта (подпроекта) своя версия кода, от которой / в которую ветвят свои персональные ветки программисты.
1.4 У каждого релиза есть своя ветка, которую тестируют перед выливанием в продакшн-среду.
1.5 Ветки проектов, которые тянутся долго, втягивают свежие версии транка, чтобы не отставать от него.
1.6 Расскажите, какие еще полезные применения системе контроля версия нашли вы в своих проектах?

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

2. Can you make a build in one step?
(Можете ли вы собрать проект одной кнопкой/командой?)
Тут несколько проще - опишите, сколько действий вам требуется, чтобы получить работоспособную версию "Х" проекта? Разумеется, речь идет не о продашкн-версии. Вопрос стоит так: Если вам необходимо пофискить баг, найденный в версии Х ветки Y - как много действий и времени занимает у вас полное разворачивание работоспособной версии этого кода, чтобы приступить к фиксу бага?

[Проблемы во многом пересекаются с предыдущим пунктом, сборка проекта является обратной стороной контроля версий. Неудачная реализация приведет к усложнению поддержки проекта, в первую очередь к усложненной процедуре фикса багов, отнимающей больше времени]

3. Do you make daily builds?
(Делаете ли вы ежедневный билд?)
Это сложнее применить к веб-проектам, но рискну дать такую трактовку: как часто делаются релизы, уходящие на продакшн, и, соответственно, как часто они тестируются (они же тестируются?). По-видимому, хорошим результатом является систематичность таких циклов, и сравнительно малая длина итерации.

[Проблема с этим пунктом приводит к потере контроля над проектом, срыву планов, большому количеству багов, частым откатам]

4. Do you have a bug database?
(Есть ли у вас база данных багов?)
Как и в случае с системой контроля версий, важен не только сам факт ее наличия, но и то, как она используется.
4.1 Да, да, мы знаем про баги, раньше мы пользовались email-ом, а теперь завели БД
4.2 Все баги проходят только через БД багов, по ней можно узнать текущую картину, нет "мелких багов, что их там вносить, я его быстрее пофикшу, чем внесу...".
4.3 БД багов интегрирована с системой контроля версий, позволяет вести и назначать списки багов, позволяя при тестировании релиза точно знать, что в нем тестировать (release plan).

[Грозит неэффективной работой с багами, при росте проекта - проблема растет экспоненциально]

5. Do you fix bugs before writing new code?
(Фиксите ли вы баги до того, как писать новый код?)
Тут, вроде, все понятно.

[Мне кажется, что это больше идеологический вопрос, чем практический]

6. Do you have an up-to-date schedule?
(Если у вас постоянно обновляемый план разработки?)
Вопрос незримо делится на две проблемы, составляя шкалу зрелости:
6.1 Есть ли у вас план разработки?
6.2 Пересматриваете ли вы этот план ежедневно, внося соответствующие коррективы?

[Грозит потерей контроля над проектом, срывом сроков, деморализацией команды]

7. Do you have a spec?
(Если ли у вас спецификация?)
Больной вопрос, правда?
Но вы хотя бы пытаетесь?

[Приводит к превышению времени и ресурсов проекта, несоответствию требованиям, сложностям в интеграции новых участников проекта, со временем и ростом - к потере контроля над проектом]

8. Do programmers have quiet working conditions?
(У ваших программистов есть тихое спокойное рабочее место?)
Ну, исходя из наших реалий - вопроса два:
8.1 Сколько квадратных местов приходится на одного программиста в вашей комнате?
8.2 Шум от работы скольки человек вы слышите во время работы? (Проще говоря - сколько человек сидит в вашей комнате?)

[Низкая эффективность, деморализация команды, текучка]

9. Do you use the best tools money can buy?
(Используете ли вы лучшие из доступных за деньги инструментов?)
В наших реалиях я бы разделил вопрос на:
9.1 Вы уверены, что пользуетесь лучшими инструментами для решения ваших задач?
9.2 Какие из ваших рабочих инструментов вы (ваше руководство, проект) готовы оплатить? (Важно: не найти аналог, а именно купить те, которыми реально пользуетесь).
9.3 Насколько у вас большой монитор? Достаточно ли мощный компьютер? Есть ли у вас лаптоп?

[Проблемы с низкой эффективностью, деморализацией команды, текучка]

10. Do you have testers?
(Есть ли у вас тестеры?)
Ответ "у нас тестируют сами программисты" - неправильный.

(Я бы поставил вопрос более широко: занимается ли каждый только своим делом? Разумно ли разделение позиций по функциям? Программисты - программируют, верстальщики - верстают, дизайнеры - рисуют, юзабилисты - проектируют, тестеры - тестируют?)

[Завышение проектного бюджета, деморализация команды, текучка]

11. Do new candidates write code during their interview?
(Пишут ли новые кандидаты код во время интервью?)
Речь идет о программистах. В общем случае вопрос стоит так: делают ли на интервью ваши новые кандитаты то, что вы хотите, чтобы они делали в дальнейшем в вашем проекте?

[Рискуете получить лишних людей, слабую команду, и как результат - текучку кадров]

12. Do you do hallway usability testing?
(Используете ли вы "коридорное" юзабилити-тестирование?)
Очень важный вопрос.
Рассуждать о юзабилити - не то.
Стараться делать юзабилити - не то.
Много читать и говорить о важности юзабилити - не то.

Вопрос стоит так: вы проверяете свои мысли-знания-навыки о юзабилити на практике, или способны только пафосно рассуждать о нем и талантливо приводить массу цитат и аргументов в пользу своей точки зрения?
То есть, даже так: как вы проверяете свои юзабилити-решения?
("коридорное тестирование" позволяет это сделать очень быстро, дешево и эффективно)

[Рискуете получить неудобный продукт]

Вот, собственно, и все.
Интересно, где находится ваша компания в этой системе координат?