ZeroBugs - очень хорошее правило, если в "баги" попадают именно проблемы клиентов в создании приложений: они не могут двигаться дальше, а замена решения очень дорога, или обходные решения есть, но довольно сложны, а сценарий по нашему мнению будет возникать у многих наших клиентов (например >10) или мы хотели что бы у них в этом сценарии сразу был другой результат. Но это на словах...
В мою работу часто попадают такие задачи: есть неожиданный или "неправильный" результат работы компонента на определенной последовательности шагов в определенном внешнем окружении. Наш клиент делал свое приложение, столкнулся с этой проблемой и написал нам "как быть?" Для его приложения этот сценарий нужен, ему надо сдавать свой заказ, а тут неожиданная проблема, на решение которой он не заложил никакого времени. Мы получили его сообщение, сказали какие есть варианты для требований к UI из его заказа, какие похожие варианты требований к UI он может предложить своему заказчику, и... Что нам лучше сделать дальше?
Дальше мы сравним эту проблеммную ситуацию с другими проблемными ситуациями: какие в них ожидания, какие будут эффекты от наших изменений, кто их заметит и насколько забуксует в своем проекте, какова сложность и вообще возможность изменения работы наших компонентов, наличие/отсутствие обходных решений, срочность задачи именно для этого клиента, важность именно этого клиента...
И затем мы выстроим задачи в наиболее оптимальную для наших клиентов очередь: мы хотим что бы как можно большее количество клиентов получило улучшения в разработке своих приложений за конкретный период нашей работы (например за месяц или за полгода). Но при этом мы хотим, что бы у клиентов из-за нашего выбора не оставались критические проблемы и что-то предпримем даже если проблема возникла только у одного клиента: предложим ему обходные решения или другой вариант настроек с немного другим внешним поведением, или предложим немного другой компонент. Для некоторых мы скажем что этот сценарий мы не рассматривали, он требует серьезных изменений и предложим рассмотреть совершенно другие способы реализации нужного поведения в его приложении.
И только некоторые сценарии-"баги" действительно встанут в очередь наших задач "вперед всех": те сценарии, которые создают проблемы у многих клиентов в создании их приложений. Те сценарии, для которых клиенты ожидают от нас решение уже через несколько дней. Те критические сценарии, с которыми по нашему мнению столкнутся многие наши клиенты в будущем. Сценарии, в которых никто не ожидает затруднений, но каждому столкнувшемуся придется сдвигать сроки выпуска своего собственного проекта/заказа.
Остальные сценарии останутся просто вопросами "Как мне сделать ХХХ?" с несколькими вариантами в нашем ответе ("Спасибо что рассказали, мы учтем это в наших планах" - один из них). Мы подготовим эти ответы и закончим работу в этот же день. У них не будет продолжения пока не изменится один важный факт: многим клиентам гораздо выгоднее делать свое приложение, когда в этом сценарии все работает сразу, чем останавливаться/вникать/обращаться/ждать/применять решение/сдвигать сроки в своем проекте. Или что-то еще... Мы же работаем с каждым новым сообщением от клиентов.
В мою работу часто попадают такие задачи: есть неожиданный или "неправильный" результат работы компонента на определенной последовательности шагов в определенном внешнем окружении. Наш клиент делал свое приложение, столкнулся с этой проблемой и написал нам "как быть?" Для его приложения этот сценарий нужен, ему надо сдавать свой заказ, а тут неожиданная проблема, на решение которой он не заложил никакого времени. Мы получили его сообщение, сказали какие есть варианты для требований к UI из его заказа, какие похожие варианты требований к UI он может предложить своему заказчику, и... Что нам лучше сделать дальше?
Дальше мы сравним эту проблеммную ситуацию с другими проблемными ситуациями: какие в них ожидания, какие будут эффекты от наших изменений, кто их заметит и насколько забуксует в своем проекте, какова сложность и вообще возможность изменения работы наших компонентов, наличие/отсутствие обходных решений, срочность задачи именно для этого клиента, важность именно этого клиента...
И затем мы выстроим задачи в наиболее оптимальную для наших клиентов очередь: мы хотим что бы как можно большее количество клиентов получило улучшения в разработке своих приложений за конкретный период нашей работы (например за месяц или за полгода). Но при этом мы хотим, что бы у клиентов из-за нашего выбора не оставались критические проблемы и что-то предпримем даже если проблема возникла только у одного клиента: предложим ему обходные решения или другой вариант настроек с немного другим внешним поведением, или предложим немного другой компонент. Для некоторых мы скажем что этот сценарий мы не рассматривали, он требует серьезных изменений и предложим рассмотреть совершенно другие способы реализации нужного поведения в его приложении.
И только некоторые сценарии-"баги" действительно встанут в очередь наших задач "вперед всех": те сценарии, которые создают проблемы у многих клиентов в создании их приложений. Те сценарии, для которых клиенты ожидают от нас решение уже через несколько дней. Те критические сценарии, с которыми по нашему мнению столкнутся многие наши клиенты в будущем. Сценарии, в которых никто не ожидает затруднений, но каждому столкнувшемуся придется сдвигать сроки выпуска своего собственного проекта/заказа.
Остальные сценарии останутся просто вопросами "Как мне сделать ХХХ?" с несколькими вариантами в нашем ответе ("Спасибо что рассказали, мы учтем это в наших планах" - один из них). Мы подготовим эти ответы и закончим работу в этот же день. У них не будет продолжения пока не изменится один важный факт: многим клиентам гораздо выгоднее делать свое приложение, когда в этом сценарии все работает сразу, чем останавливаться/вникать/обращаться/ждать/применять решение/сдвигать сроки в своем проекте. Или что-то еще... Мы же работаем с каждым новым сообщением от клиентов.
Комментариев нет:
Отправить комментарий