Тут ребята из Майкрософта рефлексируют о том, почему это произошло (две статьи, первая интересней).
“What Really Happened with Vista”: https://hackernoon.com/what-really-happened-with-vista-4ca7ffb5a1a
“What Really Happened with Vista: An Insider’s Retrospective” https://blog.usejournal.com/what-really-happened-with-vista-an-insiders-retrospective-f713ee77c239
Очень интересно, как про управление проектами, так и продуктом. Вкратце: очень хотели построить офигенный космический корабль, но не поняли, что нужно покупателям и ошиблись в общих трендах. А давление топ-менеджмента, влюбленного в свои идеи, очень долгие релизы и плохая координация не помогло увидеть и исправить эти ошибки.
Две золотых цитаты из этих статей:
One is so fundamental as to be trite. Execution matters. There is no innovation without execution.
…
“Product Management in 100 words”: https://medium.com/@mr.thomas/pming-at-google-in-100-words-85655785c6fdThe second is one that I took greatly to heart in my subsequent career. If you want to do broad ambitious things, you need to be accountable to articulate why it is the right thing to do. You need to be able to write down your basic thesis and the evidence behind it and then defend it. In fact, the more power you hold, the more accountable you need to be to open yourself to honest challenge on either facts or logic. This is even more critical in times of rapid change because the facts and consequential logic might change. Accountability and transparency means you are able to reassess your conclusions and react quickly.
Статья — набор идей, про каждую из которых можно много рассказывать.
Недавно прочитал интересный старый white paper про дизайн интерфейса в Windows 95. Если вам интересны процессы создания хорошего дизайна – стоит прочитать, остальным будет скучновато.Prioritize. Have strong opinions, weakly held. Plug the gaps. Launch and iterate. Know the user. People > products. Create team culture. Always overcommunicate. Work with people whose strengths and weaknesses complement your own. Take good notes. Your calendar is sacred. There is no such thing as an easy launch; launching good enough > never launching. Have fun, detatch, do not burn out. Always have a 20% project. Follow passions and connect the dots later. Always have a cofounder. Begging forgiveness > asking permission. Embrace the struggle. Take big risks; your failures won’t matter in two years and your successes could change the world.
Но я хотел рассказать не про эту статью, а про одну конкретную мысль из нее, которую подтверждают и мои наблюдения.
Отдельные интерфейсы для начинающих это плохо.
Когда у тебя достаточно сложный продукт, то есть соблазн дать новичкам совсем отдельный простой интерфейс. Новые пользователи смогут легко и просто начать пользоваться продуктом через этот интерфейс, а потом (в какой-то момент) переключатся на обычный более сложный.
У этого подхода есть проблемы.
1. Если новичок не нашел нужную фичу в простом интерфейсе (а там по определению нет всего — это же упрощенный интерфейс), он может подумать, что этой фичи нет в продукте и уйти.
2. После того, как пользователь освоит начальный интерфейс и переключится в “настоящий” / “полноценный”, он теряет весь накопленный опыт (и в процессе не поймет, зачем ему знать два разных пути делать одно и то же, из которых первый выученный теперь уже не нужен). В процессе онбоардинга пользователь никак не готовится к реальному использованию продукта.
3. Это разделяет интерфейсы на два типа: “простые для начинающих” и “сложные для обычных ребят”. Это не побуждает упрощать свои обычные интерфейсы.
Мы в Эквиде уже попадали в эту ловушку.
Но появляется сложный вопрос — что же делать, чтобы упростить онбоардинг в сложном продукте? Конкретного ответа пока у меня нет, но есть следующие мысли:
1. Не делать отдельные простые интерфейсы для начинающих.
2. В самом начале, например процессе регистрации, можно отдельным интерфейсом попросить что-то сделать, что упростит онбоардинг позже. Например в процессе регистрации отдельными шагами попросить подтвердить страну и, например, добавить первый товар (объявление, фотографию, etc.) Разница с #1 тут в том, что в этот интерфейс мы больше не вернемся — он нужен только для пре-конфигурации продукта после регистрации. А если что-то можно узнать и пре-конфигурировать автоматически — надо это обязательно сделать.
3. TO-DO cписок задач для начинающих – хорошая штука. Если чувак знает, что хочет – он проигнорирует. Если не знает — это поможет в ситуации “так много всего — не знаю с чего начать”.
4. Сложность в интерфейсах для начинающих можно скрывать. То есть один и тот же (это важно!) интерфейс может скрывать свои сложные штуки, которые нужны не всем и показывать их только тем, кто явно захотел их увидеть и найти. Также один и тот же интерфейс может давать больше объяснений для начинающих.
Этика — учение о том, что считать хорошим, добрым поступком, а что плохим, злым. Интересно, что всю этику можно разделить на три большие направления.- Этика добродетели
- Деонтология
- Консеквенциализм
Расскажу, как я их понимаю.
Этика добродетели
Этика добродетели определяет поступок хорошим, если его совершил бы добродетельный человек. То есть кто-то, кто наделен определенными добродетелями (доброта, справедливость, etc). То есть фокус в первую очередь на самом человек и его мотивах, а не на его действиях. Мотив поступка важен. Чтобы понять хороший поступок или плохой, надо посмотреть продиктован ли он добродетельными качествами человека, чтобы бы сделал бы в этом случае некий идеальный “добродетельный” чувак. Список добродетелей конечно у каждого философа разнится.
Деонтологическая этика
Поступок хороший, если он соответствует каким-то определенным правилам. Если не соответствует, то поступок плохой. Мотив не важен. Результат не важен. Важно — соответсвует ли он правилам. Правила могут быть разные. Например христианская этика оперирует правилами из Библии (“не убий”). Кант говорит про нерушимые нравственные законы, одинаковые для всего человечества. Это могут быть общие социальные договоренности или какие-то определенные “права человека”. Правила могут быть разными, важно следовать этим правилам, независимо от последствий. В рамках деонтологической этики не важны мотивы и последствия, важно соответствует ли действие правилам.
То есть например маньяк идет по следам вашего друга, находит вас и спрашивает — где живет ваш друг. Не ответить вы не можете, если вы ответите — маньяк уйдет. Так вот по Канту, если вы соврете (и спасете друга) — это по прежнему будет плохим поступком. Так как врать — плохо.
Консеквенциализм
Поступок хороший, если он привел к хорошим результатам и последствиям. Важен именно результат, а не мотивы или соответствие правилам. Разные ребята определяют “хорошие результаты” по разному. Есть утилитаризм, когда надо стремится максимизировать счастье максимального количества людей. Есть разумный эгоизм и просто эгоизм — максимизация своего счастья, если это не противоречит интересам других или не обращая на интересы других. Ситуационная этика, которая максимизирирует любовь и добро. Интеллектуализм — когда хороший результат это тот, который максимально увеличивает знание. И есть еще куча разных других направлений, которые определяют хороший результат самыми разными штуками.
Все они определяют хорошесть последствий по разному (также по разному смотрят на то, мог ли ты предусмотреть последствия или нет), но объединяет их одно: фокус на последствиях. Мотивы и правила не важны, важен результат и последствия.
То есть если посмотреть на действие от начала до конца, то этика добродетели фокусируется на самом начале (мотив человека и сам человек), деонтология на принятии решении делать или не делать согласно каким-то правилам, а консеквенциализм на самом конце — результате действия.
Это все очень интересно и вот почему. Мне кажется понимание и определение своих собственных принципов этики, позволяет в будущем сильно эффективнее (и быстрее!) принимать хорошие правильные решения в непонятных ситуациях, когда не сразу понятно, как будет хорошо, а как плохо.
Также осознание этих штук позволяет понять, что на самом деле мы очень часто-то не следуем или чисто деонтологической концепции или консеквенциализму. А скачем между ними в зависимости от ситуации или своих личных желаний.
Много-много смешных мемов про проблему вагонетки, которая напрямую связана с этикой. А про проблему вагонетки можно почитать в Википедии.Блумберг опубликовал статью про то, что Apple меняет свои инженерные процессы из-за того, что стало падать качество их софта. Статья не очень интересная, гораздо интереснее обсуждения, которые она вызвала.Во-первых, эпичный тред от Стивена Синофски, который много лет руководил разработкой Windows. Он рассказывает, что разработка это всегда баланс и попытка найти оптимальное равновесие между тремя полюсами: фичи, качество и дедлайны.
Немного цитат (но лучше прочитать весь тред):
11/ What is lost in all of this recent discussion is the nuance between features, schedule, and quality. It is like having a discussion with a financial advisor over income, risk, and growth. You don’t just show up and say you want all three and get a “sure”.
..
13/ In practice when building Office (and later Windows) whenever someone on the team would panic and ask “are we date driven, feature driven, or quality driven” we would just roll our eyes and pull up a chair…This was so common we just called it conversation #37 and move on.
..
19/ There’s nothing magic about this. It goes back to a balancing act. Mature orgs just manage this the whole time. There are processes and approaches that you use so you never face the absurd notion that this is a zero sum trade off between quality, schedule, features.
..
36/ You start a project with aspirations. You start with a known set of resources. You have a date. Building a plan is iterating across these constraints. Different people on the team/org with different inputs. It is an iterative process.
..
37/ Big projects run poorly are “date driven” or “we’re getting this whole thing done (famously “second system syndrome”). Lame projects are “we’re fixing bugs” (used to call this “re-indenting all the source code”.
..
Вторая интересная штука по следам статьи Блумберга о разработке в Эппл – интересный коммент на Реддите от чувака, который работал над iOS. Взгляд инженера.40/ But a product at scale serves all those needs and a strong leadership team has a long-term point of view PLUS it knows why the company exists and what it wants to do. That’s how a plan is developed. That’s what it means to build at scale.
As someone who used to work on iOS at Apple, what that company honestly needs is a culture not beholden to the whims of their EPMs (project managers). They used to help organize and work with engineering to schedule things across the company’s waterfall style development. However, by the time I left, they essentially took power over engineering. Radar became the driver for the entire company and instead of thinking about a holistic product, everything became a priority number. P0 meant, emergency fix immediately, P4 meant nice to have. You get the idea.
…
P1 P1 P1, everything is always in crises mode. Also why I and everyone around me felt bad for taking any vacation. If we weren’t constantly thinking about fixing those P1s, we were some how letting our team down.
..
This is how you get bugs in shipping software. EPMs driven to schedule things and over manage engineers would decide on a whim that something was a P2. That was basically always shelved to a follow-up .1 release.
..
У Нассима Талеба вышла новая книга “Skin in the game”. Талеб весьма интересен тем, что он не боится высказывать взгляды очень далекие от общепринятых (вспомним его статью про диктатуру меньшинства, например).Ultimately, engineers lost the freedom to decide when a feature was ready to ship. So here I see some “leak” about quality and I think, this is just PR spin for a buggy iOS 11. Unless the company is willing to take power away from the all-mighty EPM org, I just don’t see how engineering will really change.
Тут какой-то чувак написал выжимку его книги: https://twitter.com/Douglas9162/status/965904588846051328
Главная идея: мнение/убеждение это чушь, если высказывающий это мнение/убеждение не несет рисков из-за возможной ошибочности этого мнения.
Несколько наиболее понравившихся цитат.
А известная статья Талеба про диктатуру меньшинства вот.2-Opinion’s are BS generally, unless someone lives/is exposed to the risks of that opinion it is invalid
..
11-You will never convince someone that he is wrong, only reality can. ALL people should be at risk of all downside to their decisions.
..
16-Avoid taking advice from someone who gives advice for a living, unless there is a penalty for their advice.
..
17-The doer wins by doing, not convincing. E.g. if someone is trying to convince you how cool their life is then it is not cool
..
22- Theories are fine, just don’t tell people how to apply them. People with SITG decide what theories they need.
..
23-people with SITG bring simplicity. People with SITG have no benefit for added complexity. Therefore be careful of people without SITG proposing complex solutions for a problem. They have incentive to seem sophisticated instead of just solving the actual problem
..
27- If you do not take risks for your opinion you are nothing
- На английском: https://medium.com/incerto/the-most-intolerant-wins-the-dictatorship-of-the-small-minority-3f1f83ce4e15
- На русском: https://web.archive.org/web/20220125080644/https://ru.ihodl.com/opinion/2016-08-16/kak-rabotaet-diktatura-menshinstva/
Если
- какое-то меньшинство (оно может составлять 1-3% от общей популяции) не готово с чем-то мириться и готово громко про это заявлять
- большинство в принципе все равно как делать
То скорее всего социум будет делать так, как хочет это меньшинство.
Если эта штука действительно работает, то из этого следует важный вывод. Нужно всегда говорить о том, что тебя не устраивает. Нужно всегда бороться за то, чтобы все работало так, как хочется тебе - даже если ты в 1% тех, кто это хочет. Есть заметный шанс, что социум изменится под вас.