Setting UX testing routine

"UX research is expensive, it’s for big companies, we cannot afford it. Let’s rather look at quantitative metrics."

That’s something you get used to hear after quitting a job at big company and discussing UX testing with peers.

You want to know what you don’t know, so as useful as quantitative analytics may be, it won’t replace talking to people and observing how they use your product.
Continue reading Setting UX testing routine

Crafting the Product Vision

Have you seen those lonely product managers, spending weeks and weeks on writing product vision documents? I bet you have witnessed some innovation in ivory towers, when a sole person is responsible for creating a product vision.

Having a shared vision is crucial to start building and launch great product and it's really rare that one person can contribute to the it at the same level as a group of professional engineers, designers, researchers and business stakeholders. Here are the common mistakes of this approach (some of them are really easy to make as a team too:)
Continue reading Crafting the Product Vision

On Organizational Trust

I always feel there's a deep correlation between your success in organisation and whether you embrace its core values and culture. Anything could change: your job functions, your role, your boss and your department. Almost any problem may be solved, now or in the course of time. But if there's a serious mismatch between your organization values and culture and between what you consider healthy values and good culture, you're in trouble. You will keep fighting with what you find frustrating and there will be no end in sight.


So when my friends or people I care for decide to change jobs and ask for my advice, it's always about their new company culture. One of the symptoms to look at is lack or presence of organizational trust. Usually it's more easier to reach high level of organizational trust in small and more or less congeneric groups, but sometimes even big companies succeed in that.
Continue reading On Organizational Trust

Talking to engineers

Getting ready to SECR software development conference I raided Yandex library, dragging home a bunch of great books I've haven't got down to yet.


The Software Development Edge: Essays on Managing Successful Projects by Joe Marasco from IBM was among them. The book is really worth reading: there's lots of nice analogies between software development and other activities, that reveal some of the core it project principles; helpful insights about human factor in development and sound practices for managers working on improvement of what and how their teams do.

But what struck me most was an idea of how business folks should talk and formulate problems to engineers. That's a fundamental problem and I see how people make each other very unhappy while trying to solve simple communication issues every day. That's especially common among people who don't work in one team and don't feel bonds to help their team members, no matter how basic their communication skills are:)

So, if you're manager or any other person on the business side, there's a easy algorithm you should keep to when you have an issue and you need an engineer to solve it.
Continue reading Talking to engineers

Retrospectives Revised

Got bored by non-dynamical retrospectives with your team? Then you should definitely look at those three insanely cool posts by Galina Kostetskaya, agile coach at Intellectsoft and a great friend of mine.

General advice on how to do retrospectives

Here you will find some really good suggestions for those whose teams just started carrying out retrospectives and for those who feel that their retros lack life and energy.

Continue reading Retrospectives Revised

Метрики процесса и продукта

На прошлой неделе в Минске прошел Product Camp 2014.

Хочу поделиться с вами моей презентацией о data-informed менеджменте и о том, как не потеряться при измерениях метрик продукта, процесса и счастья команды.

А заодно и текстовой версией минского доклада на habrahabr.

Каждому проекту своя методология

Первая часть поста – перевод оригинальной статьи Алистера Кокберна 1999 года, остальное – авторский текст.

Любая методология основывается на страхе. Каждый элемент методологии призван предотвратить появление тех проблем, с какими автор методологии уже сталкивался в прошлом. Боитесь, что программисты сделают в коде много ошибок? Не забывайте о проверках кода. Вам кажется, что заказчики сами не знают, чего им надо? Создавайте прототипы пользовательских интерфейсов. Опасаетесь, что проектировщики уйдут в самый разгар работы? Сделайте так, чтобы они писали подробную документацию всего, что делают.

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

Как выбрать подходящую проекту методологию? Существует несколько принципов, на которые стоит ориентироваться при выборе:
Continue reading Каждому проекту своя методология