«Без ТЗ результат хз» — как часто видишь этот мем и сталкиваешься с этой фразой на работе?
ТЗ — один из основных результатов работы аналитика. В посте поделимся особенностями составления ТЗ, которые сложились в отделе аналитики Surf за годы работы с разными заказчиками.
Сегодня уделим внимание ТЗ на frontend: считаем, что backend уже готов, и в нашем арсенале имеется готовое к использованию API.
💬 Расскажи, каких правил придерживаешься при написании ТЗ? Пиши в комментариях.
ТЗ — один из основных результатов работы аналитика. В посте поделимся особенностями составления ТЗ, которые сложились в отделе аналитики Surf за годы работы с разными заказчиками.
Сегодня уделим внимание ТЗ на frontend: считаем, что backend уже готов, и в нашем арсенале имеется готовое к использованию API.
💬 Расскажи, каких правил придерживаешься при написании ТЗ? Пиши в комментариях.
👍7🔥6👏2
Аналитик на банковском проекте
И в чём отличие от привычной работы аналитика на других проектах типа e-com
1️⃣ Много подготовительной работы на старте. Нужно изучить стандарты от регулирующих органов типа НСПК (Национальной системы платёжных карт) и Центробанка, разобраться с регуляторными задачами, изучить формат банковских требований.
2️⃣ Многоуровневая система согласования ТЗ и количество ЛПР — лиц, принимающих решение. В банке, как правило, согласование происходит через несколько подразделений. Большое количество ЛПР часто создаёт эффект «сломанного телефона», а замечания с разных слоёв противоречат друг другу.
3️⃣ Сложный формат поступающих требований. В документе описаны требования ко всем системам сразу, а также миссия, общие положения и прочее: нужно учитывать время на проработку и декомпозицию требований. К тому же документ постоянно обновляется: важно следить за версиями.
4️⃣ Регуляторные задачи. Их нельзя не выполнить, иначе у банка могут отозвать лицензию. У них строгий дедлайн и жёсткие правила реализации, от которых нельзя отступать.
Как мы в Surf работаем с этими особенностями на банковских проектах, читайте в статье нашего аналитика Алисы Ковыршиной.
Читать статью >>
И в чём отличие от привычной работы аналитика на других проектах типа e-com
1️⃣ Много подготовительной работы на старте. Нужно изучить стандарты от регулирующих органов типа НСПК (Национальной системы платёжных карт) и Центробанка, разобраться с регуляторными задачами, изучить формат банковских требований.
2️⃣ Многоуровневая система согласования ТЗ и количество ЛПР — лиц, принимающих решение. В банке, как правило, согласование происходит через несколько подразделений. Большое количество ЛПР часто создаёт эффект «сломанного телефона», а замечания с разных слоёв противоречат друг другу.
3️⃣ Сложный формат поступающих требований. В документе описаны требования ко всем системам сразу, а также миссия, общие положения и прочее: нужно учитывать время на проработку и декомпозицию требований. К тому же документ постоянно обновляется: важно следить за версиями.
4️⃣ Регуляторные задачи. Их нельзя не выполнить, иначе у банка могут отозвать лицензию. У них строгий дедлайн и жёсткие правила реализации, от которых нельзя отступать.
Как мы в Surf работаем с этими особенностями на банковских проектах, читайте в статье нашего аналитика Алисы Ковыршиной.
Читать статью >>
👍7❤4
В прошлом посте мы рассказали, из каких элементов глобально должно состоять техническое задание — ТЗ.
ТЗ — это инструкция, которой разработчик руководствуется в работе. Сегодня говорим о том, что разработчику важно увидеть в ТЗ и без чего разработку начинать нельзя.
На карточках собрали советы: как сделать ТЗ, которое разработчикам будет легко читать, понимать и применять.
ТЗ — это инструкция, которой разработчик руководствуется в работе. Сегодня говорим о том, что разработчику важно увидеть в ТЗ и без чего разработку начинать нельзя.
На карточках собрали советы: как сделать ТЗ, которое разработчикам будет легко читать, понимать и применять.
🔥13👍2❤1
Баттл: кто проектирует интеграцию лучше
Разработчик vs аналитик
В разработке постоянно встаёт вопрос интеграции со сторонними сервисами. Разработчики априори лучше разбираются в средствах разработки — зачем привлекатьлюбителя аналитика?
Подготовили карточки с разбором 👉
Разработчик vs аналитик
В разработке постоянно встаёт вопрос интеграции со сторонними сервисами. Разработчики априори лучше разбираются в средствах разработки — зачем привлекать
Подготовили карточки с разбором 👉
🔥11👏2👍1
Перепись канала! Какой у тебя грейд?
Anonymous Poll
14%
Trainee
26%
Junior
20%
Middle
2%
Senior
39%
Без грейда
💡 Есть предустановленное приложение. Нужно сделать так, чтобы приложение считывало штрих-код лампочки и выдавало пользователю детальную информацию о ней.
👆👆👆 Такое задание предстояло решить участникам «Хакатона ВГУ», который мы организовали в начале марта.
Обычно хакатон — это соревнование для разработчиков. Мы поменяли формат: в нашем хакатоне участвовали полноценные команды.
В каждой команде были:
🔹 проджект-менеджер,
🔹 аналитик,
🔹 тестировщик,
🔹 фронтенд-разработчики: iOS, Android, Flutter,
🔹 бэкенд-разработчики.
На хакатоне мы воссоздали процесс работы, который бывает на реальных проектах:
🔥 У каждой команды — свой заказчик, с которым необходимо общаться, согласовывать логику и презентовать работу.
🔥 Стресс-тесты: «на ходу» появлялись новые требования, сроки сокращались, мы просили реализовать нереализуемое и двигали приоритеты задач.
🔥 Ловушки: шаблон ТЗ с частично описанной логикой, специально допущенными ошибками и логическими «ямами», специально допущенные баги в реализованных фичах.
Участникам удалось понять, как выглядит работа на реальном проекте и какую зону ответственности занимает каждая из ролей, поработать в команде, реализовать проект и презентовать его остальным участникам и жюри 😎
💬 «Я в восторге: до Surf никто не устраивал подобное. Такой опыт получаешь не каждый день, работая над реальным проектом в прямом эфире!» — Диана, BA
💬 «Это самое яркое событие за 3 года обучения! У вас получилось создать прям рабочую обстановку, организация просто на высшем уровне: начиная от концепции мероприятия, деления на роли и команды, заканчивая едой», — Иван, бэкенд-разработчик
❓ Хотели бы поучаствовать в таком хакатоне?
👆👆👆 Такое задание предстояло решить участникам «Хакатона ВГУ», который мы организовали в начале марта.
Обычно хакатон — это соревнование для разработчиков. Мы поменяли формат: в нашем хакатоне участвовали полноценные команды.
В каждой команде были:
🔹 проджект-менеджер,
🔹 аналитик,
🔹 тестировщик,
🔹 фронтенд-разработчики: iOS, Android, Flutter,
🔹 бэкенд-разработчики.
На хакатоне мы воссоздали процесс работы, который бывает на реальных проектах:
🔥 У каждой команды — свой заказчик, с которым необходимо общаться, согласовывать логику и презентовать работу.
🔥 Стресс-тесты: «на ходу» появлялись новые требования, сроки сокращались, мы просили реализовать нереализуемое и двигали приоритеты задач.
🔥 Ловушки: шаблон ТЗ с частично описанной логикой, специально допущенными ошибками и логическими «ямами», специально допущенные баги в реализованных фичах.
Участникам удалось понять, как выглядит работа на реальном проекте и какую зону ответственности занимает каждая из ролей, поработать в команде, реализовать проект и презентовать его остальным участникам и жюри 😎
💬 «Я в восторге: до Surf никто не устраивал подобное. Такой опыт получаешь не каждый день, работая над реальным проектом в прямом эфире!» — Диана, BA
💬 «Это самое яркое событие за 3 года обучения! У вас получилось создать прям рабочую обстановку, организация просто на высшем уровне: начиная от концепции мероприятия, деления на роли и команды, заканчивая едой», — Иван, бэкенд-разработчик
❓ Хотели бы поучаствовать в таком хакатоне?
🔥11❤5