Разные ситуации - разные требования
Джорж, ты работаешь в формате привлеченной звезды. На последнем проекте одной из твоих задач было даже обучение команды новому языку и параллельно написание на нем продукта. Имхо, это очень круто.
Расскажи, пожалуйста, как часто приходилось работать с выстроенными процессами?
Попадать в команду с выстроенными процессами мне приходилось несколько раз, и это зависело от масштаба компании.
При работе с корпорации выбор простой - изучить процесс как часть онбординга и следовать ему. Пересмотр и адаптация чего-то нового, по моему опыту, настолько трудоемкая задача, что проще вести своего рода "двойную бухгалтерию" - делать так как удобно и адекватнее, а отчитываться по формальному процессу.
В компании по-меньше тоже приходилось сначала принимать готовый процесс разработки. Далее, по итогам работы, инициировать совещание и вносить изменения. Есть нюанс: нельзя перестройку объявлять на совещании. Это прямой путь нарваться на сопротивление людей изменениям. Сначала лучше поговорить тет-а-тет со всеми участниками и убедить их лично, или хотя бы морально подготовить.
Доводилось работать в компаниях, где процессов совсем не было. Это было одновременно и сложно и прост: я начинал настраивать свой процесс, но по-началу все пытались лезть в обход. Не было культуры следовать процессам. Тут помогало выдерживание границ: например,"все задачи только через gitlab".
Что ты называешь отчётностью по формальному признаку?
Когда происходит формальный процесс и мы показываем, что все документы по нему заполнены. Что называется "не придерешься". С другой стороны, реальные согласования и ход работ отличались и нигде в утвержденном процессе это не фиксировали.
Ты рассказывал истории о том, в каких разных форматах получал требования. Какой формат тебе наиболее удобен?
Я считаю use-cases самым удобным форматом требований. Из него уже можно продумывать реализации. Когда я вижу use-case, я получаю максимальную гибкость для достижения цели, у меня включается творческое начало.
Обширные ТЗ хороши для согласований. В то же время они приводят к неэффективным тратам ресурсов. Те ситуации, когда исполнители не видят смысла в том что делают и делают "формально по букве".
Gherkin хорош когда надо кропотливо описать flow со всеми нюансами. Это уровень swagger - когда надо посмотреть как это должно работать в деталях, для справки. Я не видел ситуации, чтобы проектирование выполняли на Gherkin.
Тебе удобно работать с атомарными требованиями, когда аналитик булитами пишет что должна и не должна делать система?
Бывают задания когда лучше описать именно так. Например: если постановка - это следствие очень специализированного процесса с неочевидными ограничениям. Обычно все-таки удобнее видеть всю систему в целом.
Джордж, перечисли пожалуйста 3 основных момента, которые по версии Вайзмана must have должны быть в любой постановке?
1. Общая цель задачи, бизнес-задача.
2. Как сейчас.
3. Что должно быть в итоге (acceptance criteria)
Часто сейчас нет. если делается что-то новое или доработка доп.функционала. или ты о чем-то другом?
По поводу как сейчас - это может быть что то вроде «клиент сейчас составляет отчёт вручную» - не обязательно про то что сделано в проекте. Ну или можно написать что сейчас никак это не делается. По моему опыту - информация о том, что происходит сейчас очень помогает.
Чего, на твой взгляд, точно не должно быть в описании задачи?
Я думаю лучше не прописывать детали реализации. Тот случай, когда в задаче аналитик пишет json, методы и куски алгоритмов для решения задачи.
Обращаешь ли ты внимание на структуру, оформление?
Поясню откуда возник вопрос: с одной стороны на оформление уходит время. С другой стороны как-то слышала, что в процессе разработки это неважно. В состоянии включенности разработчик смотрит суть и ищет информацию, а не форматирование.
Я просто люблю когда все адекватно и просто оформлено. Сам стараюсь пользоваться markdown, еще обожаю одну фичу gitlab - когда можно в markdown задачть чекбоксы для чеклиста в задаче. Шрифты и оформление "как в Word" точно делать не стоит=)
Спасибо за интервью!