PM-Jedi Голосов: 1 Адрес блога: http://pm-jedi.blogspot.com/ Добавлен: 2012-04-20 14:16:13

Яндекс: Data & Science

2017-05-03 09:05:00 (читать в оригинале)

Выступил пару недель назад с футуристической лекцией о больших данных, полезных для здоровья.



Очень рекомендую послушать Тимофея Пыркова из Gero про то, как оценивать параметры старения с помощью обычного смартфона. Вкратце, коллеги по количеству шагов и другой двигательной активности построили дескриптор, который достаточно точно предсказывает, сколько человеку осталось жить. Звучит как фантастика.

Ну и отдельно - доклады про анализ ДНК: Чем полезны технологии больших данных в работе с бактериями микробиоты от коллег из Атласа и целая встреча Data & Science: биоинформатика - там тоже очень много интересного.

---

Про старый код

2016-01-03 00:41:00 (читать в оригинале)


Некоторое время назад написал на Хабр пару статей про отличительные свойства старого проекта со страшным и ужасным легаси кодом (Старый код: почему он такой) и о том, как правильно "продавать" рефакторинг (Техобслуживание кода: как продать рефакторинг бизнесу).

К слову, у меня есть пара примеров, когда рефакторинг удалось успешно продать заказчику (или руководству). В одном случае, заказная разработка системы зашла в тупик, и там было огромное количество багов, которые страшно раздражали. Они частично перепали нам от "изначальных индусов", а частично мы сами наплодили, пытаясь вписаться в то, что уже было к тому времени сделано.

В общем, в итоге, мы уговорили заказчика выделить нам три недели между итерациями проекта (они там были, как и положено в хенд-мейд-аджайлфолл, полугодовыми). Удалось убедить достаточно просто - путём сравнения двух оценок новой фазы проекта - без рефакторинга и с рефакторингом, которые отличались сильно в пользу второй. Ну и пообещали, что простыня багов пофиксится сама собой (кстати, так и случилось, как не странно).

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

Ну и третий проект - тоже в Яндексе - по переписыванию огромного куска инфраструктуры. Там его стартовали под общие аплодисменты, но был момент, в котором стало понятно, насколько проект большой и долгий, и его решили было прикрыть. Собственно, роль продажи заключалась в том, что мы собрались и рассказали заинтересованным лицам о том, что мы делаем и почему делаем именно так. Оказалось, что всё делаем круто и надо продолжать. В общем, рерайтинг продал сам себя :).

Есть и грустные истории про то, как не полетела "вторая версия" движка для системы потому, что программисты закопались в мелочах и попытках создать идеальную архитектуру. Но это уже другая история. И Спольски хорошо про неё пишет.

---

Про русский язык и профессиональный сленг

2015-02-05 13:40:00 (читать в оригинале)

Недавно читал большую дискуссию по поводу того, насколько глубоко в нас засел профессиональный сленг. Попробовал шутки ради написать пару строчек, которые на 100% понятны разработчикам и совершенно непонятны людям, далёким от производства ПО.

Однако, получилось:

- Вася, ты когда багу пофиксишь? Она регрессионку для релиза стопит
- Так я же её ещё в прошлом спринте пофиксил и закоммитил
- А в бранч смерджил?
- Нет пока в транке только.
- Мерджи быстрее, а то QA уже таску реопнул
- А ту минорную фичу про шаринг контента поэстимейтил?
- Это которую кастомер вчера зарепортил? Нет, нужно подольше поресёрчить
- Сделай asap, плиз
- ок

Ну и, ради соблюдения приличия - перевод (похожий на диалог двух деревянных киборгов).

Кстати, в последний раз с необходимостью такого перевода сталкивался 10 лет назад, когда писал диплом. Хотя нет... после этого я писал ТЗ для одной крупной русской компании. Тоже пришлось изголяться.

- Вася, когда ты исправишь ошибку в программе? Она не даёт нам провести регрессионное* тестирование перед вводом в эксплуатацию новой версии программы
- Я исправил ошибку в прошлом цикле разработки и внёс соответствующие изменения в систему контроля версий
- А изменения в ветку внёс?
- Нет. Пока все изменения находятся в главной линии разработки**
- Переноси их в ветку быстрее, а то инженер по контролю качества вернул задачу в состояние "открыто"
- А ты произвёл оценку трудозатрат, необходимых на реализацию новой низкоприоритетной функциональности, связанной с возможностью поделиться содержимым?
- Той, которую вчера довёл до нашего сведения заказчик? Нет.  Дополнительные исследования потребуют некоторого времени
- Пожалуйста, сделай это как можно скорее
- Хорошо

* Термин профессиональный, но устоявшийся и официальный
** Да, именно так официально называется trunk

---

Конкуренция внутри команды убивает командный дух

2014-01-12 09:41:00 (читать в оригинале)

Давно не писал сюда. Впрочем, это понятно - новая интересная работа отнимает время чуть более, чем полностью. Чего и вам желаю :)

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


В современной экономике принято считать, что конкуренция оказывает исключительно благотворное влияние на рынок. Она не даёт создаться монополии, не даёт ценам на товар или услугу превысить некие разумные пределы, заставляет производителя постоянно совершенствовать продукт, не останавливаться на достигнутом, чтобы не отстать от конкурентов.

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

Читать статью на Хабре полностью

---

Увидель продукт глазами пользователя

2013-06-28 07:27:00 (читать в оригинале)


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

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

Суть проблемы

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

Это чудесные формы по заполнению совершенно непонятной информации, как на рисунке слева.

Это закрывающиеся окошки текстового редактора, которые даже не пытаются предложить сохранить текст, на который несчастный пользователь потратил два часа своей жизни.

Мне очень грустно работать с таким ПО. Я понимаю, что его писали первоклассные специалисты, я допускаю, что код этих систем тоже в полном порядке. Однако я не стану ими пользоваться. В крайнем случае, если у меня не будет выбора, я всё-таки буду «плакать, колоться и жрать кактус», но при этом окончательно испорчу карму разработчикам своими мало литературными комментариями.