Denis Vasilyev
а какой шанс, что программист работал, а соответствующей переписки (воркэраунд, прояснения задачи, тесты, приемка и багафиксы) не было? Пусть это не измерение работы, но в качестве эвристики - быстро понять, когда реально было движение и его интенсивность - вполне.
рекламирую простой скрипт для визуализации рабочего чата в телеграм. Если работа сопровождается активным чатингом, то на графике будет сразу видно, когда был ворк, а когда простой: https://vc.ru/u/22413-denis-vasilyev/271998-podschet-i-vizualizaciya-messedzhey-v-telegram-chate
почем в итоге вышла заявка, включая все работы?
Собираем юридический FAQ по коронавирусу и карантину тоже: https://pravoznanie.com/categories/koronavirus
30. к этому конфликту нужно быть готовым. Случается это и при покраске стен, и в кабинете врача, и в любом сервисе
31. разработчик тратит всё своё время на продукт и знает детали предметной области лучше тех, кто продуктом пользуется. Так и должно быть — это правило разделения труда. Но именно поэтому важно держаться при принятии решений наиболее широкого взгляда при работе с деталями. И чутко слушать пользователей на предмет общих трендов и бессознательных запросов
32. часто люди хотят одного, но озвучивают не само желание, а представляющиеся им верными шаги по решению проблемы. Задача разработчиков — услышать то, чего именно хотят пользователи
33. система оплаты должна быть простой. В противном случае человек начинает колебаться с выбором и это может разрушить его изначальное намерение покупки
34. не нужно создавать новые фичи, отнимая время и силы от основного продукта
Независимые разработчики — не корпорация, они не могут бесконечно наращивать сложность в продукте. Сложность в дальнейшем очень дорого обслуживать. Это верный путь к разорению и закрытию проекта, поэтому главный принцип инди-разработки — умеренность и технологичность
35. всё, что способно повергнуть разработчика в трату времени, сил или ресурса, должно подвергаться внимательному самоаудиту. Важно помнить, что поддерживать продукт придётся из отпуска и по ночам, поэтому нельзя бросаться реализовывать свои или чужие фантазии. Иначе получится фичизм, превращающий продукт в bloatware
36. достаточно часто нам пишут: «Сделайте, чтобы значок был красного цвета», или «Хочу перевод транслита на лету». Сделать это мы, конечно, можем, но это придется поддерживать в работоспособном состоянии годами. Это отвлечет нас от по-настоящему важной задачи — качественного автопереключения
37. вот представьте, что основная функция автомобиля перестанет работать из-за того, что в него добавили, скажем, навороченный ароматизатор воздуха. Что скажут производителю люди, которые из-за этого не смогли попасть на работу? Конечно же: «Зачем вы этот ароматизатор туда добавили вообще?». А потому что люди просили!
38. конечно, бывают приятные исключения. Недавно человек написал: «А вы кроме даблшифта оставьте Break на отмену, без всяких настроек, пусть будет два варианта, последний — для тех, кто привык». Вот это гениально и просто — и было сделано за две минуты. Мы сами почему-то не додумались
Выжимка. Экономия - 10 тыс. символов (без упрека автору).
Советы разработчикам от создателя Punto Switcher
1. в 2018 году мы запустили новый проект - Caramba Switcher. Ниже идеи, которые помогали нам создать этот продукт
2. держите каналы фидбека всегда открытыми. Довольные пользователи отключают уведомления, а через время недовольство накапливается и они удаляются молча
3. следите, чтобы FAQ и чат-бот не стали препятствием для живого фидбека
4. помимо аккаунтов в соцсетях мы создали почтовую рассылку для оперативного общения
5. лучше не анонсировать изменения заранее, чтобы не создавать лишние ожидания. Сюрприз и анбоксинг более желательны
6. не нужно удерживать пользователей любой ценой. Это создает бесполезную нервозность: «я уйду к конкурентам»; «вот только что вы лишились кастомера». Лучше всем иметь свободу и радость выбора
7. не стоит ориентироваться на продвинутых пользователей. Решайте проблемы тех, кто не может разобраться сам
8. продвинутые пользователи обычно первыми выходят на связь, но задачи, которые они решают специфические и могут легко увести разработку не туда
9. более перспективная (хотя и более сложная) задача - понять, что беспокоит тех, кто не знает как написать в поддержку
10. long tail pressure - несовершенства продукта, которые не видны на начальном этапе разработки, но которые всплывают при увеличении пользовательской базы
11. не давайте проекту «покрыться пылью» — обновляйте сайт и соцсети. Пользователь не хочет садиться в тонущий корабль. Изображайте “живость” проекта всеми силами. Обновляйте год в копирайте
12. 30-60 секунд должно быть достаточно для ознакомления с главной информацией на сайте
13. лучше сделать маленькую и важную задачу сначала, а большую и важную — потом. Иначе можно и большую задачу не решить, и не сделать то, на что ушёл бы час
14. всё должно быть понятным, даже номера версий софта. Настоящая простота требует немалых усилий и всегда сложна по сути
15. юзеры оценят простоту. Apple часто даже не рассказывает про свои новые функции, на них натыкаешься случайно и всегда радуешься
16. изначально номера версий были понятны — Word 6 становился Word 7. Потом в номере добавилась дополнительная цифра для обозначение небольших изменений. Например, WinRar 2.1. Затем появилась третья цифра, обозначающая багфикс. Затем четвёртое число после точки — номера сборки или ревизии кодовой базы в SVN. В конце номер перестает что-то говорить пользователю: Foxit Reader 9.4.1.16828.
17. номер нашей программы содержит только информацию о ее свежести: Caramba Switcher 2019.06.20
18. уведомления не должны мешать пользователю. «right time» — время, когда допустим показ алертов пользователю. Обычно при этом срабатывают нескольких паттернов: нескольких минут отсутствия активности работы на клавиатуре и кликов мышки (состояние Idle), отсутствие показа видео
19. чем меньше настроек, тем лучше. На самом деле, у нас сотни настроек, просто они спрятаны внутри «Карамбы» и активируются динамически
20. программ, в которых автопереключение не нужно, более сотни (уже и не говорим про тысячи игр) и десятки тысяч человек заходят каждый день в настройки и, чертыхаясь, вносят очередную программу в исключения. Это крайне нетехнологично
21. мы решили добавить по умолчанию нужные исключения и языковые модели, сэкономив сотни часов юзерам
22. мы не ущемляем пользователей в правах, но работаем совместно с ними для создания коллективного удобства для всех
23. внимательные люди как-то чувствуют такие почти незаметные вещи, и им инстинктивно нравится использовать то, что избавляет мозг и тело от лишних бессмысленных действий
24. экономия в этом смысле - важный элемент разработки хороших продуктов
25. большинство людей не читает хелпы и мануалы, поэтому все проблемы пользователей разработчик должен решать заранее на своей стороне, а не пускать людей на минное поле
26. хелп - это капитуляция разработчика. Для ложки и вилки хелп не нужен
27. при получении репорта о проблемах в софте, важно определить - это «баг» или «глюк». Баг легко воспроизводится, а глюк может возникать в результате сложного многомерного совпадения различных условий
28. проблема может возникать не только в софте и компьютере, но и в сознании пользователя. «Я вам вчера писал, что не переключает, извините! Сегодня я проверил — оказывается, что переключает!»
29. профессионал пытается интегрировать в продукт коллективный опыт использования, тогда как любитель бессознательно настаивает на том, чтобы именно его персональный опыт был применен к другим пользователям
могу только поздравить с "правильной организацией" )