Понимать насколько хорошо идут дела в команде разработки нужно не только менеджерам, но и кандидатам. При выборе проекта для работы стоит серьезно относится к его текущему состоянию. На собеседовании никто не предоставит доступ к исходникам или данным по бэклогу. Выбор об участии придется делать в условиях некоторого "тумана войны".
В подобной ситуации требуется использовать какой-то более простой способ определения качества команды. Например, описанный в 2000 году Joel Test.
Суть теста - дать бинарные( "да" или "нет") ответы на 12 простых вопросов.
1. Используете ли вы контроль исходников (Do you use source control)?
В статье про git ничего не говорится, потому что первую версию git выпустили лишь в 2005(fun fact, выпустил его Линус Торвальдс для разработки Linux).
2. Возможно ли сделать сборку одним действием(Can you make a build in one step)?
3. Выполняется ли сборка ежедневно(Do you make daily builds)?
4. Ведете ли список багов(Do you have a bug database)?
5. Исправляются ли баги до написания нового кода(Do you fix bugs before writing new code)?
6. Есть ли план релизов(Do you have an up-to-date schedule)?
7. Есть ли документация(Do you have a spec)?
8. Достаточно ли спокойные условия работы(Do programmers have quiet working conditions)?
9. Лучшие ли у вас инструменты(Do you use the best tools money can buy)?
10. Есть ли тестировщики(Do you have testers)?
11. Пишет ли кандидат код на интервью(Do new candidates write code during their interview)?
12. Практикуется ли "коридорное" тестирование удобства(Do you do hallway usability testing)?
Поймайте несколько человек в коридоре и попросите провзаимодействовать с вашим продуктом. Их отзывы покроют 95% проблем с удобством пользования.
Про каждый пункт можно достаточно долго говорить о его необходимости и деталях реализации. Тут важнее наличие хоть в каком-то виде, ведь худой порядок лучше беспорядка. Многие указанные тут пункты не требуют специфических навыков и/или инструментов, это все вопросы организации рабочего процесса.
Понятное дело, что пункты выше - не панацея. Есть команды, которые могут не соответствовать им, но при этом делать крутые продукты(я слышал про кейсы, когда не используется даже гит). Однако при прочих равных жизнь в проекте, который набирает в тесте 10+ очков будет намного проще, чем в проекте с более слабым результатом(неважно, уже внутри ли вы или еще только присматриваетесь).
Если в вашем проекте не применяются какие-то из описанных выше практик - считайте данный пост поводом, чтобы это пересмотреть. Не стоит осознано проходить мимо низко висящих фруктов.
В своем телеграмм канале t.me/itkvas я разбираю разные способы подходы к улучшению рабочих процессов в IT. Подписывайтесь, если вам это интересно!
