четверг, 15 марта 2018 г.

Какие тесты мне помогают?

Такие, которые дают ответ на вопрос "Зачем должно работать именно так?"
А многие тесты в моем текущем проекте - это только утверждения "Должно работать именно так!" без намека на причину такого поведения.

среда, 14 марта 2018 г.

Почему я часто хочу иметь автоматические тесты на варианты конфигураций у конечного пользователя?

Что бы пояснить заказчику изменение поведения в терминах, понятным конечным пользователям, и получить их согласие на это изменение. Или НЕсогласие. Заказчику нужно сравнить неудобство в работе с приложением с затратами на реализацию более удобной работы и либо оплатить эти изменения, либо оставить как есть.

Например, заказчику приложения лекго принять решение после такого моего пояснения:

среда, 17 января 2018 г.

KPI


Как их сделать?
Варианты разные (например в Стратегическое планирование) и я выбрал такую исходную формулировку Цели: продукт как инструмент для получения/увеличения доходов должен быть выгодным как для его разработчиков, так и для его пользователей. Индикаторы должны давать ответ на вопросы "продукт уже труп или очень даже живчик?", "с обоих ли сторон выгодно поддерживать/развивать продукт или нет?"
Под эту цель подходят два KPI results: доходы + расходы. Мои, как создателя продукта, и доходы и расходы его пользователей, которые я тоже буду пытаться определить разными способами.

Для этих KPI результатов через полгода (все цифры и сроки гипотетические, к реальности не имеют отношения, даже если и совпадают) хочется иметь другие значения:
- A1. Доходы разработчика продукта выросли на 20%
- A2. Расходы разработчика продукта не увеличились.
- A3. Доходы пользователей продукта выросли на ХХ%
- A4. Расходы пользователей продукта не увеличились.

*Разбор вариантов для "доходы/расходы пользователей" я пока отложу. Возможно, я разберу их позже, но пока я буду просто учитывать, что для разработчика продукта они так же важны как его собственные.

Через полгода эти результаты будут показывать один из трех вариантов: ничего не изменилось, стало хуже, стало лучше. Или промежуточные варианты.

На каждый из этих результатов разработчик продукта может повлиять.

Сейчас 5000 клиентов продляют лицензию каждый год (5000 * $600 = $3 000 000) и еще 500 клиентов покупают новую лицензию каждый год (500 * $3000 =  $1 500 000).

Итого доходы за год: 4 500 000. Общая сумма не важна, потому что ее составляющие зависят от разных действий наших клиентов и влиять на каждое из них нужно по разному:

- A1.1. Новую лицензию стали покупать больше на 20%: больше покупок новой лицензии на 300.
- A1.2. Продлять лицензию стали больше на 20%: больше продлений на 1500.
- A1.3. Промежуточные варианты между 1.1 и 1.2.

*В раскладе конкретного продукта конечно надо изучить "есть ли столько отказов от продления лицензии?", "как изменилось количество продляющих лицензию клиентов за последние 365 дней по сравнению с предыдущим периодом" и др. От этого будет зависеть приоритет изучения дальнейших шагов. TODO: разобрать эти варианты позже? Они довольно занимательны и важны.

Есть и другие варианты измерений (воронка продаж, NPS, подписчики каналов, просмотры/оценка материалов), но их я бы приложил к каждому из моих конкретных шагов в направлении A1. После того как конкретные шаги будут сделаны, эти способы помогут мне измерить эффективность шагов, оценить выбор шагов из доступных вариантов, скорректировать мои выбор/оценку/прогнозы и наверное много чего еще (TODO: написать про это позже?).

Итого мне надо получить такие изменения в продукте что бы "отказов от продления лицензии стало на 1500 меньше" или что бы "покупок новой лицензии стало на 300 больше". Промежуточные варианты или даже оба сразу тоже подойдут. Каждый вариант подразумевает Расходы, в тексте я буду их учитывать, но немного позже (TODO: а может с ними и так все понятно?).

*Можно использовать формулировку "продления лицензии стало на 1500 больше", но она зависит от нескольких факторов, ее результатом можно управлять с помощью изменения результата "покупок новой лицензии стало на 300 больше", поэтому я ее не буду использовать.

Получилась вменяемая формулировка задачи. Для ее решения я изучал (месяц, два или полгода) сценарии использования продукта, реальные заказы на разработку конечных приложений, ручные доработки в конечных приложениях, сложности использования, аналогичные продукты, провел другие мероприятия по методам Метод1, Метод2, Метод3 (TODO: нужно ли перечислять реальные способы?), выявил несколько возможностей разных изменений для A1.1 и их влияние на доходы от продукта как для разработчика, так и для клиентов.

И вот что получилось.

B1. Добавить в продукт готовую возможность просматривать и изменять данные с форматированием как в Word и хранение этих данных в базе, экспорт/импорт в разные форматы как в Word, печать этих данных

Новую лицензию на продукт с этой возможностью купят (по моим методам предсказания):
- 100 новых клиентов - каждый год после выпуска в течение примерно 10 лет
- 300 отказавшихся от продления лицензии клиентов (300 только только в этот год, потом ради этой возможности из отказников купят лицензию 50)

Ради этой возможности лицензию продлят (в дополнение к тем кто и без нее будет продлевать лицензию):
- 300 клиентов - и будут продлять дальше каждый год после выпуска в течение примерно 10 лет (+ позже сколько-то клиентов продлят из тех кто теперь решится купить)

Для этого варианта осталось оценить затраты на разработку и сопровождение этого изменения (TODO: нужно ли их расписывать в этом посте?). У меня получилось $1000 в месяц на 2 года, потом $100 потому что будут сразу готовы почти все возможности для почти всех задач и документация станет простой/понятной.

Неплохое изменение, я ожидаю увеличение сразу и по новым ползователям и по продлениям лицензии. И расходы выглядят небольшими.

Пока что это предсказания, реальные результаты будут известны значительно позже изменения.

А прямо сейчас есть и другие варианты, ведь одного этого по моим предсказаниям маловато для достижения нужных изменений в KPI результатах:
B2. ... я не могу брать формулировки реального продукта и мне лень придумывать суть, вариант аналогичен предыдущему, отличия только в цифрах
B3. аналогично, отличия только в цифрах
B4. аналогично, отличия только в цифрах
B5. аналогично, отличия только в цифрах

Возможны и другие изменения, не касающиеся именно функционала продукта.

Например, такие:

C1. Увеличить информированность людей, которым подходит наш продукт. Например, через рекламу, или через наши собственные статьи о решении реальных задач с помощью нашего продукта, или через посты наших клиентов о решении их задач с помощью нашего продукта.

Но с рекламой возможно появление клиентов, которым наш продукт не очень подходит и у нас возрастут затраты на сопровождение, а количество негативного публичного опыта использования продукта увеличится. Нужен эксперт для оценки принципиальной возможности такой рекламы, для оценки затрат на нее и эффективности от этой рекламы. Я не могу выполнить такую оценку, но это изменение все равно возможно.

C2. Увеличить стоимость продукта - про этот вариант у меня знаний еще меньше.

С3. Другая схема получения прибыли, например с привлечением третьих участников как с рекламой на google.com.

После составления списка вариантов осталось только выбрать из них наиболее многообещающую комбинацию и делать ее варианты в специальном порядке с учетом риска "за полгода все не сделаем" (и других рисков).

Все. На этом можно считать первую половину законченной. Дальше пойдет вторая половина, третья и так далее... :-)

KPI показывает не цель, а постоянное движение к цели. Я перечислил варианты, но они не появились за полдня. Это работа предыдущего месяца, двух или за полгода. И она основана на работе по предыдущим вариантам достижения той же Цели: какие изменения были выбраны для реализации полгода назад и каков эффект от их реализации? 

Вот полгода назад я их выбрал и за полгода сделал, сейчас они стали доступны моим клиентам и ?.. Какие про них мнение у клиентов? Они помогают им зарабатывать больше денег? Они им нравятся? Им приятно работать с этими изменениями? Он довольны появлением этих изменений? Ответы на эти вопросы помогают мне определить правильно ли я выбрал и использовал методы предсказания результатов и что мне следует изменить в моей работе с этими инструментами и методами. Эта тема выглядит второй половиной. Ее мне описывать лень, она неплохо расписана в Чем занимается Product Marketing Manager в JetBrains. Там конечно слова "МАРКЕТИНГ", но общение с клиентами - это хороший способ получения обратной связи, корректировки собственной работы по выбору/планированию следующего шага для достижения нужного KPI и проверки эффективности используемых способов/инструментов.

По такому описанию получается циклический процесс, в котором предыдущий цикл существенно влияет на следующий. Однако схема работы с KPI результатами остается такой же и с каждым разом сделать их становится легче.

вторник, 31 октября 2017 г.

Понятные тесты...

Да, опять тесты...

Вот такие тесты сейчас я нахожу очень понятными (в таком формате я и чужие тесты понимаю, и свои многолетней давности):

    [TestFixture]
    public class RibbonFormTests {
        [Test]
        public void RibbonForm_ControlsAddRibbon_SizeSet700x700_Show() {
            using(RibbonForm form = new RibbonForm()) {
                form.Controls.Add(new RibbonControl());
                form.Size = new Size(700, 700);
                form.Show();
                Application.DoEvents();
                Assert.AreEqual(700, form.DesktopBounds.Width);
                Assert.AreEqual(700, form.DesktopBounds.Height);
            }
        }

вторник, 4 июля 2017 г.

Как тестировать расширение поведения контрола?

Например использую я в своем приложении Grid. Лежит он у меня на в одном из окошек. На нем вообще много разных контролов, я закладки сделал и грид у меня на второй закладке. Источник данных для грида у меня умненький: данные загружает только при реальном обращении. Я его сразу в грид присваиваю, код простой получается, а сам грид не пытается сразу же данные зачитывать. И это правильно, ведь закладка-то у него вторая, еще не открытая, и я ожидаю что он не будет загружать данные и увеличивать время для открытия окна. Зато на открытии закладки он сам данные зачитывает, ведь теперь он видимый стал. Очень такой хороший грид. В этом сценарии.

А в соседнем сценарии грид уже не так хорош: если вторую закладку открыть, потом первую закладку, обновить все данные в окне (и сразу же присвоить ему источник данных), то он сразу же зачитает эти данные. Хотя находится на неактивной закладке и его сейчас не видно. Как же быть?

среда, 5 апреля 2017 г.

"Заказчик"/"Product Owner" для вендора компонент?

С этой ролью легко получить разницу с вариантом из Экстремального Программирования: "Заказчик платит - вы делаете" уже не будет соответствовать реальности.

пятница, 3 марта 2017 г.

Как начать планирование релиза?

Попался на глаза этот старый драфт поста, уже несколько лет ждет публикации и все еще выглядит актуальным.
Вот, наконец, дождался....

"Выпуск релиза каждые полгода" и все такое. У этой модели много разных названий, а сама модель работы очень надежная и эффективная. Вот только на каждые полгода ощущается "трение": один релиз уже выпущен, а работа на цели следующего релиза все не начинается и не начинается... Как же так?

Имхо, вполне нормальная ситуация: всегда есть недоделки. Количество недоделок на конкретную дату зависит от "качества" работы в предыдущие полгода. Наделали много долгов - будет много недоделок. Наваяли код, обложили тестами, сделали документацию, наклепали примеров, подготовили презентации, провели тестирование всего этого на "тестовых клиентах", внесли исправления по выявленным проблемам - и долгов будет мало. Трение на старте нового релиза зависит только от этого.
С увеличением размера продукта такое трение становится более разнообразным: 10 человек наделали разное количество долгов и кто-то сидит допоздна каждый день, а кто-то дергает за рукав со словами "ну когда уже релиз планировать будем?" Такая ситуация тоже вполне нормальна и нет смысла откладывать работу только для того, что бы "начать работать над новым релизом одновременно" и именно такой подход мне кажется наилучшим.
Это отличный вариант, но с ним вполне можно "бежать впереди паровоза" и действовать неадекватно "мировой ситуации":
  • В целом по команде не должно быть явных перекосов по долгам, когда у кого-то пусто, а у кого-то полные штаны этих долгов.
  • Установленные критерии качества соблюдаются (ошибки быстро исправляются, вопросы быстро отвечаются).
  • В целом по продукту усилия должны быть приложены по направлениям, которые все признают важными (цели на год-два).

Поэтому я же таким энтузиастам начинаю "вставлять палки в колеса" в соответствии с этими пунктами:
  • "У тебя баги кончились? Фиксить нечего? Вопросы по твоим фичам не задают?"
  • Почему бы тебе вместо нового кода не помочь поправить известные ошибки в новом коде фичи Х? Ах не ты делал... А какая разница? Все равно эти ошибки придется исправлять и чем раньше начнем, тем быстрее получим хорошее качество. Перераспределим ресурсы адекватно реальности.
  • Почему бы тебе вместо твоей идеи "а давайте сделаем Х!" не заняться моей идеей "сделать У"?
  • Вот у нас трафик вопросов большой и специалисты поддержки почти по ночам уже сидят - помоги им раз уж закончил со своей работой по выпущенному релизу. Посмотри почему у них такой завал и как улучшить ситуацию?
К счастью энтузиастов, у меня количество таких палок весьма ограничено и можно заранее подготовиться к попыткам "вставлять их в колеса" и начать таки работать на новый релиз:
  • Да кончились. Да, нет багов. И вопросов тоже нет.
  • Либо фичам готова к выпуску в релизе, либо нет. В новом релизе могу помогать, а сейчас лучше выпилить сырую фичу из релиза.
  • Вон опрос провели и выходит, что нафиг не нужен твой "У", все голосовали за мой "Х". И вопросы я еще посмотрел - то же самое выходит, список вопросов в приложении 1.
  • Вот кто выпустил то, из-за чего специалисты сидят - тот пусть и помогает. Опять же премиями можно мотивировать. А я прошлом релизе начал и закончил так, что никто нигде не засиживается. И могу еще что-нибудь сделать с таким же результатом.
Если есть понятные ответы на эти вопросы, то нет причин откладывать работу. Можно "прям щас" составить план на себя в новом релизе и сразу же начать по нему работать.