Решаем проблему заказчика, а не слепо выполняем задание (AnalystDays-8 2018-04) — различия между версиями

Материал из MaksWiki
Перейти к: навигация, поиск
м
м
Строка 1: Строка 1:
 
  Выступление 27.04.2018 на [https://analystdays.ru/ru/program/55425 AnalystDays-8]
 
  Выступление 27.04.2018 на [https://analystdays.ru/ru/program/55425 AnalystDays-8]
  [https://analystdays.ru/ru/talk/59036 Доклад на сайте конференции]
+
  [https://analystdays.ru/ru/talk/59036 Доклад на сайте конференции], там '''ссылка на видео''' за 1$ (есть подписка)
  
 
Заказчики часто формулируют запрос на разработку как идею конкретного функционала. Исполнители в свою очередь начинают немедленно проектировать требуемое, не выяснив, какие проблемы предполагается решить. В результате разработанное решение не устраивает клиента, и у этого может быть несколько причин. Во-первых, идея заказчика может изначально не соответствовать ситуации. Во-вторых, детали реализации могут сделать решение неверным, даже если замысел был правильным. В-третьих, бывает, что задание можно выполнить проще и быстрее. Поэтому аналитик должен выяснить проблемы у заказчика уже на первом этапе проекта.
 
Заказчики часто формулируют запрос на разработку как идею конкретного функционала. Исполнители в свою очередь начинают немедленно проектировать требуемое, не выяснив, какие проблемы предполагается решить. В результате разработанное решение не устраивает клиента, и у этого может быть несколько причин. Во-первых, идея заказчика может изначально не соответствовать ситуации. Во-вторых, детали реализации могут сделать решение неверным, даже если замысел был правильным. В-третьих, бывает, что задание можно выполнить проще и быстрее. Поэтому аналитик должен выяснить проблемы у заказчика уже на первом этапе проекта.

Версия 10:59, 22 августа 2018

Выступление 27.04.2018 на AnalystDays-8
Доклад на сайте конференции, там ссылка на видео за 1$ (есть подписка)

Заказчики часто формулируют запрос на разработку как идею конкретного функционала. Исполнители в свою очередь начинают немедленно проектировать требуемое, не выяснив, какие проблемы предполагается решить. В результате разработанное решение не устраивает клиента, и у этого может быть несколько причин. Во-первых, идея заказчика может изначально не соответствовать ситуации. Во-вторых, детали реализации могут сделать решение неверным, даже если замысел был правильным. В-третьих, бывает, что задание можно выполнить проще и быстрее. Поэтому аналитик должен выяснить проблемы у заказчика уже на первом этапе проекта.

В докладе я расскажу о том, как это сделать, и приведу примеры, как меняются пути решения после погружения в бизнес-замысел проекта.

Solving the client’s problem rather than blindly doing the task

Clients often accompany their request for new features with an idea of what exactly it is necessary to develop. Performers, in their turn, embark on designing the features required immediately, without finding out what problems they are supposed to solve. As a result, the solution developed does not meet the client’s expectations, and this may be due to several reasons. First, the customer’s idea may not be relevant to his situation initially. Secondly, the solution may turn out to be wrong because of the details of the implementation. Thirdly, it happens that the task can be accomplished faster and easier. For this reason, the analyst should define the client’s problems as early as on the first stage of the project.

My presentation demonstrates how it can be done and provides the examples of how the immersion into the business plan of the project changes the ways of solving the problem.

Презентация

Скачать весь pdf
ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf ProblemSolving-NotDoingTask - Tsepkov AnalystDays-2018.pdf