| Сегодня 3 июня, понедельник |
      |
  
|
  
Какой рейтинг вас больше интересует?
|
Главная /
Каталог блоговCтраница блогера PM-Jedi/Записи в блоге |
 |
|
Как программисты пишут часы. Опасности общих моделей
2012-04-21 17:15:00 (читать в оригинале) |
| Именно так выглядят часы, дизайн которых придумал программист |
Не могу не поделиться замечательным случаем, который произошёл у нас в команде несколько дней назад.
В рамках нашего нового продукта ребята разрабатывали интерактивные виджеты для HTML5. И, в какой-то момент, дело дошло до анимации. Естественно, анимация представляла собой красивый и плавный переход между состояниями. Действительно, программисты довольно быстро и аккуратно всё реализовали, и я, вспомнив вебдевную молодость, выпросил недоделанный компонент "поиграться".
Но тут возникла непредвиденная заминка. Часы отлично шли до тех пор, пока секундная стрелка не доходила до отметки 59. А потом... Да, вы правы. Она красиво и плавно обращалась вспять и, пройдя весь циферблат в обратном порядке, возвращалась к отметке 0.
И ведь с точки зрения программистов всё выглядело логично! Действительно, чтобы анимировать переход от значения 59 к значению 0, надо, чтобы стрелка прошла в обратном порядке все числа от 59 до 0. Вот только в реальности никто никогда не видел часы, в которых стрелка возвращалась бы назад...
Итак, что же полезного мы можем вынести из этой ситуации?
- Во-первых: чтобы описать любой объект или явление, программистам приходится строить модель. По определению модели, часть факторов из реальной жизни остаётся "за бортом". И в этот момент особенно важно следить, чтобы модель, которую построили программисты, соответствовала модели, которую строит для себя пользователь. Действительно, когда я отключил анимацию, часы стали вести себя вполне ожидаемо (хотя и не так красиво).
- Во-вторых: тестирование должно обязательно проводиться на реальных данных в условиях, максимально приближенных к тем, который возникают у пользователя. Сейчас это кажется очевидным. Однако иногда, желая досконально протестировать работу продукта в граничных случаях и под нагрузкой, мы можем упустить проверку самых очевидных кейсов, которые, в силу их тривиальности, все просто игнорируют (и забывают).
- В-третьих: обычно программисты пишут программы, а не продукты. Они увлекаются описанием объектной модели, построением архитектуры и алгоритмов, забывая о том, что продукт должен собой представлять в реальности. То есть надо возвращать их с неба на землю. Здесь сильно помогает итеративный подход и частая демонстрация промежуточных результатов владельцу продукта (честно говоря, затрудняюсь более точно перевести скрамовское сочетание product owner).
- В-четвёртых: если вы пишите ТЗ на разработку внешней команде, по возможности описывайте исходный объект или процесс из реальной жизни, который лежит в основе создаваемого ПО. Это не только позволит программистам увидеть задачу шире, чем программный код, но и вы сможете более чётко сформулировать ключевые требования.С другой стороны я с огромным трудом представляю себе ТЗ, которое содержит фрагмент типа "при переходе от 59 к 0 стрелки должны двигаться по часовой стрелке". Такая детализация возможна разве что в системе жизнеобеспечения космического корабля, но мне такие задания, к сожалению, пока читать не доводилось. Поэтому описание реального объекта поможет команде более точно понять задачу.
- В-пятых: идеальный программист всегда немного аналитик. Он мыслит не только интерфейсами, классами и методами, но и объектами предметной области, понимает не только алгоритмы, но и бизнес-логику системы. И это одна из основных черт, которая отличает опытного разработчика от начинающего кодера (каким бы классным он ни был).
В заключение хочу сказать, что никоим образом не пытаюсь посмеяться над "глупыми программистами" или как-то ещё задеть их в профессиональном плане. У меня отличные ребята и классная команда. Просто есть вещи, которые кажутся настолько очевидными, что перестаёшь обращать на них внимание и видеть исключения из общих правил. И поэтому очень важно смотреть на систему с разных сторон: как менеджер по продукту, как аналитик, как программист, как пользователь системы. Попробуйте, и ваши продукты будут великолепны! Как у нас :).
Пара слов о дневнике проекта
2012-04-18 19:01:00 (читать в оригинале)Конфуций сказал однажды: «умный человек учится на своём опыте, мудрец — на чужом». В этой статье я постараюсь сделать ещё один шаг в направлении к «умному человеку» и поделиться, как можно аккумулировать свой опыт в течение проекта.
Известно, что наступать на грабли больно, обидно и неприятно. Впрочем, если грабли лежат в совершенно неожиданном месте, были оставлены там только что, а на дворе глубокая ночь и ни черта не видно, это позволительно. Наступать же на грабли во второй раз не только больно обидно и неприятно, но ещё и стыдно.
Как не наступать на грабли менеджеру проекта? Вопрос, на самом деле, не очевиден. Понятно, что от этого нет универсального лекарства. Первый и самый простой вариант — «это придёт с опытом». Именно поэтому, опыт — это очень ценный ресурс, потерю которого нужно минимизировать. Один из таких способов максимально сохранить опыт от прошедших проектов я активно применяю и сейчас вам его опишу. Называется он – дневник проекта.
Что я понимаю под «дневником проекта»
Итак, сначала определимся, о чём идёт речь вообще. Под дневником проекта я понимаю абсолютно тривиальную вещь — таблицу, в которую я записываю значимые события, возникающие в течение проекта. Я фиксирую как свои решения, так и события, имеющие, на мой взгляд, влияние на ход проекта. Например:
· Дал Васе задачу по аналитике. Надеюсь, что справится хорошо. В этом случае смогу сосредоточиться на управлении и взаимодействии с заказчиком, а аналитику частично делегировать ему
· Отправил Васю в неплановый отпуск на 2 недели. Решение принял спонтанно, глядя на его измученный вид. Это немного задержит проект, но повысит работоспособность Васи
· Приложение одобрено Apple, но отозвано по инициативе заказчика из-за ошибок в разделе X. Ошибки были найдены на нашими QA в процессе тестирования, но мной было принято решение, не считать их критичными и выпустить приложение (примечание автора: да, мне стыдно про это вспоминать, но факт имел место)
· Произвели впечатление на заказчиков и получили бонус
В общем, видно, что большинство записей – описание моих решений с комментариями по поводу их эффективности. И видно, что большинство решений – ошибочные.
Структура записей
Каждая запись состоит из четырёх колонок: дата, описание, категория и выводы.
- Описание – это развёрнутый текст, где в нескольких предложениях описан факт, возникший в течение проекта. Примеры описаний приведены в предыдущем разделе.
- Категория – простейшая классификация событий. У меня их, собственно, три: win, fail и "???". Очевидно, что первая говорит, что решение или фактор был удачным, вторая – показывает, что мы сильно «пролетели» из-за данного решения, а в случае с третьей категорией – я ещё не определился, считать ли данное событие успешным. Ещё иногда встречается категория draw (событие никак не повлияло на проект), но он появляется крайне редко.
Бывает, что запись из одной категории кочует в другую. Например, запись «Дал добро на рефакторинг секции X. Будем смотреть, окупятся ли те 40 часов, которые он должен занять» кочевала из категории fail, когда рефакторинг затянулся на две недели, в категорию win, когда в результате получили чистую и аккуратную версию, которую тут же успешно сдали заказчику, сэкономив кучу времени на багфиксах в изначально «пластилиновой» реализации.
Или, ещё нагляднее: «Продолжаю задерживать команду допоздна в дни деплоев» сначала имело категорию win, т.к. мы уложились в короткие сроки и получили значительный бонус от заказчиков (естественно, команда была довольна высокой премией). Непосредственно после этого один из ключевых разработчиков начал откровенно «проскальзывать» на пустом месте, и стало очевидно, что он «перегорел». Пришлось отправить его в отпуск, и проект затянулся гораздо сильнее, чем мог бы, если бы мы работали «ровно» всё время. В результате, факт задержки команды по ночам перекочевал из win в fail. - Выводы – на мой взгляд, наиболее важная колонка. Здесь я максимально полно пытаюсь описать, какие результаты повлекло данное событие, и какие выводы из этого мне надо сделать. Это, конечно же, самое трудное.
Вообще, выводы могут быть самыми простыми и очевидными, например «Необходимо хранить документы в системе контроля версий»
Примечание автора: эта запись появилась после того, как я нечаянно перезаписал файл с оценками на итерацию и вынужден был полдня их восстанавливать.С другой стороны, вывод может занимать много строк, как, например: «На этапе анализа необходимо требовать примеры того, как должен выглядеть результат. Это стимулирует заказчика продумать, что он хочет получить. То же самое для изменений: видимо, нельзя начинать работу до тех пор, пока не будет одобрен интерфейс. Не имеет смысл полагаться на текстовые описания (особенно, плохие) – всегда нужна картинка»
Примечание автора: речь идёт о недостаточно проработанном текстовом ТЗ на изменение части системы, которое мы в спешке приняли, поверив, что заказчик знает, как лучше. Потом, после реализации первой версии, оказалось, что заказчик хотел совсем другое, но не написал это. Пришлось разводить долгую (и, слава Богу, успешную) дипломатию с заказчиком с убеждением его в том что он, на самом деле, хочет совсем другое, а не то, что написал.
Заключение
Мой последний проект, который занял несколько тысяч человеко-часов, имел дневник на пяти страницах. Перечитывая его, я иногда ужасаюсь, как мог допустить ту или иную глупость, которая, естественно, повлекла серьёзные последствия. Но, если быть с собой до конца честным и регулярно перечитывать то, что написал, не разрешая себе списывать неудачи на внешние факторы, то вполне можно избежать подобных ошибок в будущем. На что очень надеюсь.
P.S. Хочу заострить внимание, что примеры могут являться вымышленными, а совпадения – случайны
Пара слов о дневнике проекта
2012-04-18 19:01:00 (читать в оригинале)Конфуций сказал однажды: «умный человек учится на своём опыте, мудрец — на чужом». В этой статье я постараюсь сделать ещё один шаг в направлении к «умному человеку» и поделиться, как можно аккумулировать свой опыт в течение проекта.
Известно, что наступать на грабли больно, обидно и неприятно. Впрочем, если грабли лежат в совершенно неожиданном месте, были оставлены там только что, а на дворе глубокая ночь и ни черта не видно, это позволительно. Наступать же на грабли во второй раз не только больно обидно и неприятно, но ещё и стыдно.
Как не наступать на грабли менеджеру проекта? Вопрос, на самом деле, не очевиден. Понятно, что от этого нет универсального лекарства. Первый и самый простой вариант — «это придёт с опытом». Именно поэтому, опыт — это очень ценный ресурс, потерю которого нужно минимизировать. Один из таких способов максимально сохранить опыт от прошедших проектов я активно применяю и сейчас вам его опишу. Называется он – дневник проекта.
Что я понимаю под «дневником проекта»
Итак, сначала определимся, о чём идёт речь вообще. Под дневником проекта я понимаю абсолютно тривиальную вещь — таблицу, в которую я записываю значимые события, возникающие в течение проекта. Я фиксирую как свои решения, так и события, имеющие, на мой взгляд, влияние на ход проекта. Например:
· Дал Васе задачу по аналитике. Надеюсь, что справится хорошо. В этом случае смогу сосредоточиться на управлении и взаимодействии с заказчиком, а аналитику частично делегировать ему
· Отправил Васю в неплановый отпуск на 2 недели. Решение принял спонтанно, глядя на его измученный вид. Это немного задержит проект, но повысит работоспособность Васи
· Приложение одобрено Apple, но отозвано по инициативе заказчика из-за ошибок в разделе X. Ошибки были найдены на нашими QA в процессе тестирования, но мной было принято решение, не считать их критичными и выпустить приложение (примечание автора: да, мне стыдно про это вспоминать, но факт имел место)
· Произвели впечатление на заказчиков и получили бонус
В общем, видно, что большинство записей – описание моих решений с комментариями по поводу их эффективности. И видно, что большинство решений – ошибочные.
Структура записей
Каждая запись состоит из четырёх колонок: дата, описание, категория и выводы.
- Описание – это развёрнутый текст, где в нескольких предложениях описан факт, возникший в течение проекта. Примеры описаний приведены в предыдущем разделе.
- Категория – простейшая классификация событий. У меня их, собственно, три: win, fail и "???". Очевидно, что первая говорит, что решение или фактор был удачным, вторая – показывает, что мы сильно «пролетели» из-за данного решения, а в случае с третьей категорией – я ещё не определился, считать ли данное событие успешным. Ещё иногда встречается категория draw (событие никак не повлияло на проект), но он появляется крайне редко.
Бывает, что запись из одной категории кочует в другую. Например, запись «Дал добро на рефакторинг секции X. Будем смотреть, окупятся ли те 40 часов, которые он должен занять» кочевала из категории fail, когда рефакторинг затянулся на две недели, в категорию win, когда в результате получили чистую и аккуратную версию, которую тут же успешно сдали заказчику, сэкономив кучу времени на багфиксах в изначально «пластилиновой» реализации.
Или, ещё нагляднее: «Продолжаю задерживать команду допоздна в дни деплоев» сначала имело категорию win, т.к. мы уложились в короткие сроки и получили значительный бонус от заказчиков (естественно, команда была довольна высокой премией). Непосредственно после этого один из ключевых разработчиков начал откровенно «проскальзывать» на пустом месте, и стало очевидно, что он «перегорел». Пришлось отправить его в отпуск, и проект затянулся гораздо сильнее, чем мог бы, если бы мы работали «ровно» всё время. В результате, факт задержки команды по ночам перекочевал из win в fail. - Выводы – на мой взгляд, наиболее важная колонка. Здесь я максимально полно пытаюсь описать, какие результаты повлекло данное событие, и какие выводы из этого мне надо сделать. Это, конечно же, самое трудное.
Вообще, выводы могут быть самыми простыми и очевидными, например «Необходимо хранить документы в системе контроля версий»
Примечание автора: эта запись появилась после того, как я нечаянно перезаписал файл с оценками на итерацию и вынужден был полдня их восстанавливать.
С другой стороны, вывод может занимать много строк, как, например: «На этапе анализа необходимо требовать примеры того, как должен выглядеть результат. Это стимулирует заказчика продумать, что он хочет получить. То же самое для изменений: видимо, нельзя начинать работу до тех пор, пока не будет одобрен интерфейс. Не имеет смысл полагаться на текстовые описания (особенно, плохие) – всегда нужна картинка»
Примечание автора: речь идёт о недостаточно проработанном текстовом ТЗ на изменение части системы, которое мы в спешке приняли, поверив, что заказчик знает, как лучше. Потом, после реализации первой версии, оказалось, что заказчик хотел совсем другое, но не написал это. Пришлось разводить долгую (и, слава Богу, успешную) дипломатию с заказчиком с убеждением его в том что он, на самом деле, хочет совсем другое, а не то, что написал.
Заключение
Мой последний проект, который занял несколько тысяч человеко-часов, имел дневник на пяти страницах. Перечитывая его, я иногда ужасаюсь, как мог допустить ту или иную глупость, которая, естественно, повлекла серьёзные последствия. Но, если быть с собой до конца честным и регулярно перечитывать то, что написал, не разрешая себе списывать неудачи на внешние факторы, то вполне можно избежать подобных ошибок в будущем. На что очень надеюсь.
P.S. Хочу заострить внимание, что примеры могут являться вымышленными, а совпадения – случайны
(Ссылка) Задача без сроков не решается
2012-04-16 07:48:00 (читать в оригинале)Неплохой пост по планированию продуктовой разработки. Всё точно сказано.
Продуктовая разработка, будучи противопоставленной разработке заказной, для меня имеет огромное множество плюсов. Тут и возможность полноценно погрузиться в задачу, и долго и вдумчиво итерация за итерацией совершенствовать и развивать проект, и непосредственное взаимодействие с конечными пользователями, и отсутствие внешнего прописанного в договоре срока, к которому так или иначе, хочешь не хочешь, пусть и ценой недоделок надо запустить проект. Прописанный срок регулярно приводит к гонкам, выкидыванию тестирования и отладки (да, срок и функционал прописан в договоре, а вот тесты... кто ж их кроме программеров видит), запуску откровенно сырого и нежизнеспособного продукта. Зачастую менеджеры творят просто чудеса в убеждении заказчика, что на самом-то деле всё работает.
Читать дальше.
(Ссылка) Задача без сроков не решается
2012-04-16 07:48:00 (читать в оригинале)Неплохой пост по планированию продуктовой разработки. Всё точно сказано.
Продуктовая разработка, будучи противопоставленной разработке заказной, для меня имеет огромное множество плюсов. Тут и возможность полноценно погрузиться в задачу, и долго и вдумчиво итерация за итерацией совершенствовать и развивать проект, и непосредственное взаимодействие с конечными пользователями, и отсутствие внешнего прописанного в договоре срока, к которому так или иначе, хочешь не хочешь, пусть и ценой недоделок надо запустить проект. Прописанный срок регулярно приводит к гонкам, выкидыванию тестирования и отладки (да, срок и функционал прописан в договоре, а вот тесты... кто ж их кроме программеров видит), запуску откровенно сырого и нежизнеспособного продукта. Зачастую менеджеры творят просто чудеса в убеждении заказчика, что на самом-то деле всё работает.
Читать дальше.
