Мы осветили технические моменты в главах «Готовое решение VS кастомная разработка» и «Реализация и разворачивание чата». С удовольствием ответим на дополнительные вопросы, задавайте :)
Добрый день! Жаль, что вы не добрались дальше прелогин-зоны, ведь все самое интересное и полезное именно там! ;) Как разработчик вы, конечно, знаете, что продуктов без багов не бывает. С момента релиза в начале июля мы выпустили уже четыре апдейта (один как раз сегодня) и продолжим улучшать приложение дальше. Спасибо за интерес к нашей работе! :)
Видимо деньгами из золотовалютных резервов накопленного за долгие годы работы программистом и продажником.
Разумеется, каждый случай надо рассматривать конкретно, но в целом именно так (что касается наемных сотрудников). Что касается руководства — горящие глаза + номинальная зарплата.
Если стартапер просит у инвестора миллионы на зарплаты, но при этом не в состоянии предоставить подтверждение (например, несколько заключенных контрактов) того, что проект начнет приносить деньги, то такой стартапер либо обманывается сам, либо обманывает инвестора.
Здесь нет вопроса первичности, но смысл я похоже передал. Если результатами могут воспользоваться и враги, например, то анализ отделен от цели.
ИМХО.
Если результатом могут воспользоваться другие люди, в том числе и враги, то вы сделали свою работу правильно.
Это значит требования качественные: полные, понятные, непротиворечивые и так далее по списку.
Если Вы сможете написать статью про анализ трудоемкости работ аналитика с цифрами, я думаю, многие скажут Вам спасибо. А заодно и то, как планировать работу над трудными задачами, не укладывающимися в стандартную временную сетку. Это очень полезный опыт.
Да, думаю это действительно интересно и дополнительная возможность систематизировать данные знания для себя лично.
Мог бы предложить следующий способ деления: Все вместе — это проект. В рамках проекта необходимо поставить задачу. Результатом постановки задач являются перечень стейкхолдеров и их интересов.
Далее происходит бизнес-анализ. На этом этапе собираются, анализируются и документируются сведения об изучаемой системе.
Затем происходит анализ полученных результатов и формулировка предложений по изменению системы.
На мой взгляд проект не равен бизнес-анализу, потому что сам анализ лишь часть проекта.
Достаточно философский подход. Что первично? Курица или яйцо…
Переведу в более понятную для меня форму. Я предпочитаю рассматривать аналитику как независимый процесс, который само по себе целостный. Его результат — это набор проектных артефактов и конкретных решений.
Может ли кто-то другой использовать этот результат, не связанный с нашим проектом? Может и зачастую так и происходит.
Мне нравится ваша точка зрения. Она не тривиальна.
1. Как оценить сроки работ бизнес-аналитика? То есть. как оценивать загрузку, на основе каких критериев? Я увидел, что это очевидно для Вас. Может поделитесь опытом?
Оценка работ для аналитика процесс весьма сложный. Скажу честно угадать точно до сих пор не удается.
Показатель точности зависит от многих факторов: знание предметной области, особенности взаимодействия с заказчиком, опыт коллег и тд.
Для начала нужно лично для себя определить, что для нас является мерилом. Я использую Use Case. Сложность конкретной задачи можно примерно оценить по количество сценариев, которые требуется написать для её покрытия.
Так же в данном случае очень помогает помодоро таймер. Во-первых, он задает ритм рабочего дня и помогает концентрироваться. Во-вторых, по количество помидоров можно определить сколько времени потребовалось на анализ той или иной задачи.
Подобные задачи можно оценивать по трудоемкости относительно друг друга.
Важно сделать оговорку, что если мы говорим о проекте «с чистого листа», то точность оценки может существенно пострадать в виду большого количества неопределенностей.
На самом деле я использую несколько техник для оценки. Думаю стоит описать это в отдельной статье. Вы навели меня на мысль )
ИМХО неверное определение. Анализ — это просто описание. Оно может приносить пользу стейкхолдерам, или не приносить — не имеет значения. Использовать результаты анализа можно как в пользу так и во вред. Это все равно, что от математики требовать полезности. Вы так не думаете?
Не могу согласиться. Автоматизация ради автоматизации — распилка проектного бюджета и сейчас уже не интересна. Бизнес процесс должен зарабатывать (предполагать выгоду для заказчика)
Задача аналитика — найти грань между удовлетворением интересов бизнеса и конечных пользователей, правильно её сформулировать (бизнес анализ) и перевести на язык разработчика (системный анализ).
Анализ — это просто описание.
В случае документирования требований да, но стоит не забывать, что это только одна из частей.
Получается, вы проводите оценку не по детальным требованиям, а по концептуальным? Не выстреливают ли в связи с этим риски? Как с этим боретесь?
Для оценки данного набор требований достаточно. Это набор атомарных (детальных и независимых) User Stories, а так же специальные требования зафиксированные в виде примечания к story + прототипы экранов от дизайнеров.
Такой подход позволяет сократить реворк на этапе системного анализа, а так же является стимулом для обсуждения и не ограничивает дизайнера.
Приведу пример:
Если я запишу требование в формате «Приложение должно...», то мы получим четко сформулированную постановку. Отклонение от неё недопустимо.
Если записать требование в формате «Я как пользователь хочу иметь возможность...», то данная формулировка подразумевает множество вариантов решения данной задачи. А уже какой это будет вариант я фиксирую на этапе системного анализа.
Тема процесса очень актуальна и интересна, с нетерпением ждем. Особенно интересно было бы услышать в статье какого типа у вас контракты (преобладают) — Time & Material, Fixed Price?
Постараюсь подготовить данный материал как можно раньше. Он требует более детальной проработки.
Если не секрет, какие UML диаграммы вы используете и для иллюстрации каких аспектов — в большей степени для того чтобы зафиксировать онтологию домена или структуру процессов? Диаграммы рисуете в каком-либо специализированном под UML CASE-средстве или же «стандарт де факто» для многих аналитиков — Microsoft Visio?
Павел, используем в основном UseCase и Activity Diagram. Не брезгаем swimline'ми и стараемся описывать полную картину взаимодействия пользователь и приложения.
Так же применяем диаграмму классов, чаще в статистическом виде.
Нет, не Visio. Используем продукт компании Sparx — Enterprise Architect.
Отдельный очень актуальный вопрос — пробовали ли использовать UML для моделирования уровня UI? Если да, насколько эффективным это вам показалось?
Скажу честно, нет не пробовали и я лично не вижу особого смысла. Во-первых, есть специализированные средства. Во-вторых, дизайнер может сделать прототип в разы быстрее и эффективнее.
В Роботе мы стараемся разграничивать область ответственности дизайнеров и аналитиков. Конечно, от явного пересечения на этапе бизнес анализа не уйти, работаем в паре.
UML можно использовать для проектирования. Например, Activity Diagram повторяют набор шагов на карте экранов.
Не за что, надеюсь она действительно полезна.
Я отвечу на вопросы и воздержусь от детального описания процесса. Оставлю эту тему как лакомый кусок на другой раз.
Мозговой штурм используем, но по необходимости. Повторять подобное каждый спринт не эффективно с точки зрения временных затрат (личное мнение). Применяем для построения концепций по конкретной фиче.
DFD да, но опять же по необходимости. Данные диаграммы нужны, на мой взгляд, на начальном этапе для устранения неопределнностей. Если же идёт фаза развития, то они могут занимать много времени. Практика хорошая, но не панацея. Можете меня ругать за это ). Чаще обходимся UML.
Бизнес правила, само собой. Без их учёта говорить о полноте требований нельзя.
Ну собственно да, UML используем, правда как схематичное изображение описанных текстовым способом требований. Я стараюсь распространять правило среди аналитиков, что полагаться на одни лишь схемы нельзя. Возможно это двойная работа, но в действительности необходимое правило.
Поясню.
Мы разделяем работу аналитика на уровни: бизнес уровень и системный уровень.
Изначально аналитик проводит бизнес анализ и описывает бизнес уровень, формирует требования в виде User Stories.
User Stories попадают на оценку проектной командой (не буду углубляться в процесс оценки).
Когда решение о включении определенного набор US в спринт принято, начинается этап системного анализа и проектирования. Требования детализируются и формулируются в формате ЧТЗ, Use Cases. Вот уже данные требования проходят ревью проектной командой.
Да, спринты длятся по месяцу.
Хочу заметить, что тема процесса актуальна и будет описана в отдельной статье. Здесь я постарался описать мой личный Toolset, которые помогает в работе.
Добрый день.
Да, действительно вопрос связан скорее с процессом и в планах появление статьи на эту тему.
Попробую кратко ответить на вопрос.
Как описано в статье — все задачи по проекту ведутся в JIRA, требования в Confluence.
Основным источником, которые все агрегирует — эпическая история в JIRA. Она агрегирует подзадачи и ссылки на требования в Conflunce. Получается dependency ))
Собственно сложно назвать такие фичи растекшимися. В своей работе я стараюсь агрегировать требования в одном источнике (Confluence), снабдить зависимые требования перекрестными ссылками. А уже в JIRA сфокусировать разработчика на конкретные требования.
Надеюсь сумел ответить на вопрос. Повторюсь, вопрос обширный и требует отдельной статьи. Думаю она появится в скором времени.
Выбор языка я подозреваю на первом экране не спроста.
Язык приложения, зависит от того, какая у пользователя выбрана локаль. Например, если пользователь выбрал английский язык, то тексты в приложениях также будут на английском так, что выбирать язык приложения вручную обычно пользователям не приходится.
На сечет выбора даты из календаря не соглашусь.
Минимальный размер элемента с которым пользователь может взаимодействовать должен составлять не менее 44 поинтов. На экране списка городов высота строки значительно меньше.
Например, нужно найти билеты на 20 декабря. В каком случае пользователь потратит больше времени: прокручивая барабан или один раз нажав на кнопку в календаре?
Вы видимо не часто попадаете на маршруты, по которым едут «номера» поездов, в которых ехать ну никак не хочется.
Конечно, такие поезда бывают. Не на всех маршрутах ходит так много поездов, чтобы их приходилось искать по номеру. Приоритетные параметры, по которым пользователь выбирает поезд, показаны в в концепте.
Где эта возможность у вас в концепте?
На мой взгляд, не стоит заставлять пользователя указывать количество пассажиров заранее, если он это всегда может сделать на этапе выбора места.
«Шаг 2. Выбор поезда» концепт выглядит менее информативно
Для пользователей, которые ищут какой-то определенный тип места предусмотрена фильтрация результатов поиска.
«Шаг 5. Покупка билета» у вас финансовая ошибка в концептах
Т.к. это лишь концепт, билеты тут продаются без сервисного сбора.
В общем, сами попробуйте в своём концепте решить следующие задачи
Хорошее замечание про тип вагона, стоит добавить эту макрикровку. Информация о доступности ЭР на поезд присутствует. В остальном сценарий покупки билета, как для одного, так и для нескольких человек легко и понятно выполняется.
Чат был сделан с нуля, и это была весьма интересная история, о которой скоро будет отдельный пост.
Если стартапер просит у инвестора миллионы на зарплаты, но при этом не в состоянии предоставить подтверждение (например, несколько заключенных контрактов) того, что проект начнет приносить деньги, то такой стартапер либо обманывается сам, либо обманывает инвестора.
ИМХО.
Если результатом могут воспользоваться другие люди, в том числе и враги, то вы сделали свою работу правильно.
Это значит требования качественные: полные, понятные, непротиворечивые и так далее по списку.
Да, думаю это действительно интересно и дополнительная возможность систематизировать данные знания для себя лично.
Достаточно философский подход. Что первично? Курица или яйцо…
Переведу в более понятную для меня форму. Я предпочитаю рассматривать аналитику как независимый процесс, который само по себе целостный. Его результат — это набор проектных артефактов и конкретных решений.
Может ли кто-то другой использовать этот результат, не связанный с нашим проектом? Может и зачастую так и происходит.
Мне нравится ваша точка зрения. Она не тривиальна.
Оценка работ для аналитика процесс весьма сложный. Скажу честно угадать точно до сих пор не удается.
Показатель точности зависит от многих факторов: знание предметной области, особенности взаимодействия с заказчиком, опыт коллег и тд.
Для начала нужно лично для себя определить, что для нас является мерилом. Я использую Use Case. Сложность конкретной задачи можно примерно оценить по количество сценариев, которые требуется написать для её покрытия.
Так же в данном случае очень помогает помодоро таймер. Во-первых, он задает ритм рабочего дня и помогает концентрироваться. Во-вторых, по количество помидоров можно определить сколько времени потребовалось на анализ той или иной задачи.
Подобные задачи можно оценивать по трудоемкости относительно друг друга.
Важно сделать оговорку, что если мы говорим о проекте «с чистого листа», то точность оценки может существенно пострадать в виду большого количества неопределенностей.
На самом деле я использую несколько техник для оценки. Думаю стоит описать это в отдельной статье. Вы навели меня на мысль )
Не могу согласиться. Автоматизация ради автоматизации — распилка проектного бюджета и сейчас уже не интересна. Бизнес процесс должен зарабатывать (предполагать выгоду для заказчика)
Задача аналитика — найти грань между удовлетворением интересов бизнеса и конечных пользователей, правильно её сформулировать (бизнес анализ) и перевести на язык разработчика (системный анализ).
В случае документирования требований да, но стоит не забывать, что это только одна из частей.
Для оценки данного набор требований достаточно. Это набор атомарных (детальных и независимых) User Stories, а так же специальные требования зафиксированные в виде примечания к story + прототипы экранов от дизайнеров.
Такой подход позволяет сократить реворк на этапе системного анализа, а так же является стимулом для обсуждения и не ограничивает дизайнера.
Приведу пример:
Если я запишу требование в формате «Приложение должно...», то мы получим четко сформулированную постановку. Отклонение от неё недопустимо.
Если записать требование в формате «Я как пользователь хочу иметь возможность...», то данная формулировка подразумевает множество вариантов решения данной задачи. А уже какой это будет вариант я фиксирую на этапе системного анализа.
Постараюсь подготовить данный материал как можно раньше. Он требует более детальной проработки.
Павел, используем в основном UseCase и Activity Diagram. Не брезгаем swimline'ми и стараемся описывать полную картину взаимодействия пользователь и приложения.
Так же применяем диаграмму классов, чаще в статистическом виде.
Нет, не Visio. Используем продукт компании Sparx — Enterprise Architect.
Скажу честно, нет не пробовали и я лично не вижу особого смысла. Во-первых, есть специализированные средства. Во-вторых, дизайнер может сделать прототип в разы быстрее и эффективнее.
В Роботе мы стараемся разграничивать область ответственности дизайнеров и аналитиков. Конечно, от явного пересечения на этапе бизнес анализа не уйти, работаем в паре.
UML можно использовать для проектирования. Например, Activity Diagram повторяют набор шагов на карте экранов.
Я отвечу на вопросы и воздержусь от детального описания процесса. Оставлю эту тему как лакомый кусок на другой раз.
Мозговой штурм используем, но по необходимости. Повторять подобное каждый спринт не эффективно с точки зрения временных затрат (личное мнение). Применяем для построения концепций по конкретной фиче.
DFD да, но опять же по необходимости. Данные диаграммы нужны, на мой взгляд, на начальном этапе для устранения неопределнностей. Если же идёт фаза развития, то они могут занимать много времени. Практика хорошая, но не панацея. Можете меня ругать за это ). Чаще обходимся UML.
Бизнес правила, само собой. Без их учёта говорить о полноте требований нельзя.
Ну собственно да, UML используем, правда как схематичное изображение описанных текстовым способом требований. Я стараюсь распространять правило среди аналитиков, что полагаться на одни лишь схемы нельзя. Возможно это двойная работа, но в действительности необходимое правило.
Поясню.
Мы разделяем работу аналитика на уровни: бизнес уровень и системный уровень.
Изначально аналитик проводит бизнес анализ и описывает бизнес уровень, формирует требования в виде User Stories.
User Stories попадают на оценку проектной командой (не буду углубляться в процесс оценки).
Когда решение о включении определенного набор US в спринт принято, начинается этап системного анализа и проектирования. Требования детализируются и формулируются в формате ЧТЗ, Use Cases. Вот уже данные требования проходят ревью проектной командой.
Да, спринты длятся по месяцу.
Хочу заметить, что тема процесса актуальна и будет описана в отдельной статье. Здесь я постарался описать мой личный Toolset, которые помогает в работе.
Да, действительно вопрос связан скорее с процессом и в планах появление статьи на эту тему.
Попробую кратко ответить на вопрос.
Как описано в статье — все задачи по проекту ведутся в JIRA, требования в Confluence.
Основным источником, которые все агрегирует — эпическая история в JIRA. Она агрегирует подзадачи и ссылки на требования в Conflunce. Получается dependency ))
Собственно сложно назвать такие фичи растекшимися. В своей работе я стараюсь агрегировать требования в одном источнике (Confluence), снабдить зависимые требования перекрестными ссылками. А уже в JIRA сфокусировать разработчика на конкретные требования.
Надеюсь сумел ответить на вопрос. Повторюсь, вопрос обширный и требует отдельной статьи. Думаю она появится в скором времени.
Язык приложения, зависит от того, какая у пользователя выбрана локаль. Например, если пользователь выбрал английский язык, то тексты в приложениях также будут на английском так, что выбирать язык приложения вручную обычно пользователям не приходится.
Минимальный размер элемента с которым пользователь может взаимодействовать должен составлять не менее 44 поинтов. На экране списка городов высота строки значительно меньше.
Например, нужно найти билеты на 20 декабря. В каком случае пользователь потратит больше времени: прокручивая барабан или один раз нажав на кнопку в календаре?
Конечно, такие поезда бывают. Не на всех маршрутах ходит так много поездов, чтобы их приходилось искать по номеру. Приоритетные параметры, по которым пользователь выбирает поезд, показаны в в концепте.
На мой взгляд, не стоит заставлять пользователя указывать количество пассажиров заранее, если он это всегда может сделать на этапе выбора места.
Для пользователей, которые ищут какой-то определенный тип места предусмотрена фильтрация результатов поиска.
Т.к. это лишь концепт, билеты тут продаются без сервисного сбора.
Хорошее замечание про тип вагона, стоит добавить эту макрикровку. Информация о доступности ЭР на поезд присутствует. В остальном сценарий покупки билета, как для одного, так и для нескольких человек легко и понятно выполняется.