Согласен)
Мне кажется этап брейншторма сценариев стейкхолдерам очень «хрупкий». Стейкхолдеры могут не обладать нужными навыками что бы придумать эти сценарии, могут забыть про ключевые моменты. А это самый важный этап этого воркшопа.
У вас перед воркшопом идет подготовка и уже есть наброски сценариев и есть уже стандартные сценарии которые накопились по опыту разработки других систем. Хотя в ссылках которые в статье, про эту подготовительную работу не сказано. Там только надежда на стейкхолдеров, которым нужно помочь забренштормить сценарии.
Основные направления которые нужно прорабатывать это производительность, доступность, безопастность, модифицируемость. Так же есть еще совместимость, надежность.
Есть какой-то список/чеклист по которому можно не забыть важные нефункциональные требования?
Добрый день, Евгений!
Спасибо большое, что поделились отзывом.
Преподаватели в школе, действительно, все разные и по уровню профессионализма, и по личностным качествам. Выбрать «своего» среди них бывает иногда очень непростой задачей. Мы стараемся со своей стороны с помощью кураторов выявлять ситуации неэффективности работы студента с преподавателем, как в случае в вашей супругой. Однако, к сожалению, не всегда это получается так хорошо, как хотелось бы.
Что касается вашего вопроса по продолжению изучения английского после уровня Advanced, то в этом случае мы обычно рекомендуем студентам занятия на курсе подготовки к сдаче одного из международных экзаменов на знание английского языка, например, IELTS www.englishdom.com/course/ielts
Но тут еще важно понимать ваши цели в изучении языка, где и для чего вы планируете его больше всего использовать.
Насчет вопроса про темную тему, да согласен, еще баги остались, но мы скоро их поправим)
Еще раз спасибо за сообщение и благодарим, что занимаетесь английским с EnglishDom.
Спасибо за вопрос,
Бизнесу просто говорим, что например нужно обновить библиотеки и сделать после этого рефакторинг, займет столько времени нужны такие разработчики. Говорим что желательно сделать это в течении ближайшего времени, и бизнес ищет ближайшее окно, где будет меньше фич и задач. Также объясняем, если не сделать рефакторинг — проект будет устаревать и его поддерживать просто будет невозможно. Невозможно будет искать новых разработчиков и фичи будут делатся медленнее.
Плюс ко всему у нас с бизнесом доверительные отношения, мы продуктовая компания, и всегда все фичи от бизнеса делаем вовремя и в полном объеме.
Насчет поддержки продукта и рефакторинга. В течении спринта, пользователи пишут например что это работает долго/медленно, qa когда тестируют или делают регрессию могут тоже написать про проблемы, сами разработчики на дейликах говорят о проблемах, на ретроспективе могут сказать про проблемы в коде/продукте. Все это мы фиксируем в наш бэклог по техдолгу и вначале каждого спринта приоритезируем и берем эти самые 10%.
Так же слышал что некоторые команды используют SonarQube, он им помогает с поиском мест для рефакторинга, мы не юзаем — но в планах есть.
Спасибо,
да есть такая проблема, некоторые vpn сервисы (которые proxy) не поддерживают websocket протокол, а через него у нас идет вся синхронизация EDClass
При 2х недельных спринтах — это да один рабочий день. Но команда у нас из 10 человек, это на 80 часов задач мы можем закрыть техдолга. А это уже не мало. (но спринты у нас не двух-недельные)
Часто в новые фичи уже заложен рефакторинг и техдолг, для этого создается специальная сабтаска и уведомляется заказчик, что его фичу можно сделать только если провести рефакторинг. И эта сабтаска не входит в 10% рефакторинга, так как она идет напрямую с задачей.
10% это минимум, конечно когда нам надо что-то сделать большое, мы описываем цель этих задач, декомпозируем, оцениваем по времени и утверждаем с бизнессом, если это выходит за 10%. Чаще всего идут на встречу и уже в спринте выходит
Вообще у нас беклог техдолга состоит из
Слышал от ребят из других компаний, что в конце года, берут 2 спринта на техдолг. Это тоже вариант неплохой, когда у компании в это время «не сезеон».
Но мы так пробывали, и целый спринт заниматься рефакторингом и техдолгом — очень уныло)
Когда у нас не было продакт-менеджера, мы сами решали какие фичи добавлять, но не всегда это было уместно. Все таки продакты нужны и важны. У наших продакт менеджеров есть фреймворки и методы определения нужных фич, они проводят интервью, собирают фидбеки, проводят опросы и после релиза фичи наблюдают за ней.
Мы пользовались как и своими решениями так и решениями аналогичных сервисов и на основе этих ощущений предлагаем фичи. Но это мы делаем в свободное время, а вот у продакт менеджеров есть прямая задача, анализа конкурентов и поиск нужных решений
Насчет анализа, мы используем в качестве продуктовой аналитики инструмент Amplitude. Очень помогает принимать решения основываясь на количественных данных. Например смотрим какой раздел популрянее, какой быстрее проходят, а какой сложнее.
Спасибо за отзыв!
В продуктовых компаниях и в стартапах чаще всего роли объеденены, поэтому иногда разработчики общаються с пользователями. Да и вообще так легче держать руку на пульсе, особенно когда зарелизили что-то не то)
очень сильно влияет на это размер компании как продуктовой так и аутсорс
Сейчас переписываем в EDWords на новые рельсы, что бы увеличить скорость работы и уменьшить количество ошибок. Поэтому есть заминка с выкаткой новых фич.
Я передам еще раз в отдел product ваше пожелание.
Спасибо!
Курс FullStack Developer 2018 с трудоустройством
Длительность курса: 6 месяцев, от 4 до 8 часов занятий каждую неделю
Это жесть, JS выучить за 10 месяцев более менее реально, а тут сразу FullStack и за 6 месяцев
відтепер платимо 20+% монобанку та пб, а країні 2%?