Аналитик из провинции: системный анализ и ИТ-карьера
15
подписчиков
Системный аналитик из Кирова.
Пишу, как без связей вырасти в ИТ: требования, инструменты, карьера.
Просто и по делу — понятно новичку, полезно практикующему.
Если ты не из центра, но хочешь в ИТ — заходи.
Подписывайся.
Системный аналитик из Кирова.
Пишу, как без связей вырасти в ИТ: требования, инструменты, карьера.
Просто и по делу — понятно новичку, полезно практикующему.
Если ты не из центра, но хочешь в ИТ — заходи.
Подписывайся.
20 часов назад
• Вы подписаны
Повторное использование требований: как не изобретать велосипед
Скопировал требование из прошлого проекта «по привычке», а оно не работает в новой реальности. Переиспользование спасает месяцы, только если это проверка и адаптация, а не копипаст. Это восемнадцатая глава книги Карла Вигерса «Разработка требований к ПО», которую я разбираю в рубрике «Книжный клуб». После проверки требований кажется, что самое сложное позади. Но есть тема, которая экономит месяцы: повторное использование требований. У большинства проектов много общего: логин, оплата, уведомления, права доступа...
21 час назад
• Вы подписаны
Как проверять требования: рецензирование и валидация
Заказчик поставил подпись «утверждено», не прочитав ни строки, и через три месяца команда переделывает всё с нуля. Утверждение ради галочки становится самой дорогой формой экономии времени в проекте. Это семнадцатая глава книги Карла Вигерса «Разработка требований к ПО», которую я разбираю в рубрике «Книжный клуб». После приоритизации у меня есть список требований, который команда готова делать. Но прежде чем отдать его в разработку, стоит остановиться и проверить, а правильно ли всё записано. Вигерс посвящает этому главу про утверждение и проверку требований...
22 часа назад
• Вы подписаны
Приоритизация требований: как развести «всё срочно» через MoSCoW
«Всё срочно, всё важно» - слышишь это каждую неделю? Команда тянет всё параллельно, к релизу - 20 функций «наполовину» и удивлённый заказчик, который получил не то. Приоритеты решают это до того, как потрачены деньги и нервы. Это шестнадцатая глава книги Карла Вигерса «Разработка требований к ПО», которую я разбираю в рубрике «Книжный клуб». После прототипов у тебя может собраться список требований, который невозможно сделать за раз. И тут приходит заказчик и говорит: «Всё срочно, всё важно». Знакомо?...
22 часа назад
• Вы подписаны
Прототипы: как снизить риск до написания кода
Ошибка в требованиях, найденная на макете, стоит рублей. Та же ошибка, обнаруженная после релиза, стоит недель переделок и испорченных отношений. Чтобы поймать её дёшево, достаточно показать заказчику что-то руками, ещё до первой строки кода. Это пятнадцатая глава книги Карла Вигерса «Разработка требований к ПО», которую я разбираю в рубрике «Книжный клуб». После того, как сделать НФТ измеримыми, остался практичный инструмент, который снижает риск на самых ранних этапах: прототипы. Ведь заказчик почти всегда не может объяснить, что ему нужно, пока не увидит хоть что-то своими глазами...
2 дня назад
• Вы подписаны
Как сделать нефункциональные требования измеримыми: Planguage и SLA
«Быстро» это сколько секунд? Пока на этот вопрос нет цифры, разработчик и заказчик правы по-своему. Хорошая новость: есть простой приём, который превращает пожелание в требование, которое можно проверить. Это вторая часть главы книги Карла Вигерса «Разработка требований к ПО», которую я разбираю в рубрике «Книжный клуб». В первой части про НФТ я разобрал, что это такое и почему их забывают. Теперь самое важное: как превратить НФТ (нефункциональные требования) из пожелания в измеримое требование, потому что «система должна быстро работать» это не требование, а мечта...
