Comments 17
>Кому нужен ваш продукт, если вы сами им не пользуетесь, предпочитая продукт конкурентов? Какого он качества? Зачем вы вообще его выпускаете и кого пытаетесь обмануть?
>Если вы хотите разработать по-настоящему нужный продукт – обязательно пользуйтесь им. Иначе будет очень сложно оценить его качество, надёжность и удобство использования.
Это хорошо работает, только если ваш продукт для программистов.
Например на IDEA писать IDEA, или что разработчики TeamSity используют его у себя постоянно.
Это хорошо и правильно.
Но вот что делать программистам, которые делают продукт для сторонних сфер?
Например программы для продавцов. Программисты не торгуют, у них нет торговых точек и т.д.
Или же например какая нибудь встраиваемая штука для автомобилей, самолетов, поездов…
Т.е. в ситуации, когда создаваемый продукт не может быть использован в процессе создания этого продукта.
А ведь в большинстве случаев это именно так.
>Если вы хотите разработать по-настоящему нужный продукт – обязательно пользуйтесь им. Иначе будет очень сложно оценить его качество, надёжность и удобство использования.
Это хорошо работает, только если ваш продукт для программистов.
Например на IDEA писать IDEA, или что разработчики TeamSity используют его у себя постоянно.
Это хорошо и правильно.
Но вот что делать программистам, которые делают продукт для сторонних сфер?
Например программы для продавцов. Программисты не торгуют, у них нет торговых точек и т.д.
Или же например какая нибудь встраиваемая штука для автомобилей, самолетов, поездов…
Т.е. в ситуации, когда создаваемый продукт не может быть использован в процессе создания этого продукта.
А ведь в большинстве случаев это именно так.
Я уверен, что помимо написания кода программисты ещё иногда живут :). Они используют сервисы навигации, ищут информацию в интернете, играют в боулинг и лазертаг, ходят на дни рождения к друзьям, дарят подарки любимой девушке, копают тёщин огород :)
Я к тому, что не обязательно делать продукты для разработчиков, чтобы ими пользоваться. Я слышал замечательную историю о ребятах, которые для написания софта о логистике купили фуру и полгода колесили по стране.
Про встроенную штуку — вопрос немного более сложный. Кто её пользователи? Вероятно те, кто её встраивают. Сможете ли вы её встроить на самом деле? Сможете ли вы попасть на атомную станцию, чтобы протестировать софт для её оптимизации? Всё зависит от вас. И не акт, что получится. В этом случае придётся просто долго наблюдать их работу и представлять себя на их месте.
Я к тому, что не обязательно делать продукты для разработчиков, чтобы ими пользоваться. Я слышал замечательную историю о ребятах, которые для написания софта о логистике купили фуру и полгода колесили по стране.
Про встроенную штуку — вопрос немного более сложный. Кто её пользователи? Вероятно те, кто её встраивают. Сможете ли вы её встроить на самом деле? Сможете ли вы попасть на атомную станцию, чтобы протестировать софт для её оптимизации? Всё зависит от вас. И не акт, что получится. В этом случае придётся просто долго наблюдать их работу и представлять себя на их месте.
«чёрт возьми, я опять промахнулся мимо этого элемента на экране смартфона, т.к. автобус тряхнуло!» — обычный кекс тоже так не скажет, он скажет «б… ть» и закроет чудо-приложение.
Программа на скриншоте — не иначе, раннее творение от создателей PaintCad for Windows.
Чтобы нормально пользоваться гитом большинству разработчиков нужно ставить гитфлоу, иначе это инструмент чужих для хищников. После меркириула у меня волосы вставали дыбом от мелочей, нужных последовательностях и нужных параметров. Гит рулит, когда вы ведёте несколько стабильных версий продукта, как ядра в линуксе.
Но не смотря на свою инородность и оверхед для большинства, он стал популярным инструментом, потому как через неделю и пару мануалов ты свыкаешься со всеми неудобствами и восхищаешься функциональностью продукта. Хороший интерфейс не тот, который вам нравится после парочки использований, а тот, который обеспечивает функциональность и скорость при постоянном юзании.
Кстати, чтобы оценить эту самую функциональность и удобство, нужно заниматься не эстетикой, а мат анализом. Нужно собирать статистику об использовании функционала, о скорости заполнения формы и делать это автоматически, не полагаясь полностью на мнение пользователей.
Но не смотря на свою инородность и оверхед для большинства, он стал популярным инструментом, потому как через неделю и пару мануалов ты свыкаешься со всеми неудобствами и восхищаешься функциональностью продукта. Хороший интерфейс не тот, который вам нравится после парочки использований, а тот, который обеспечивает функциональность и скорость при постоянном юзании.
Кстати, чтобы оценить эту самую функциональность и удобство, нужно заниматься не эстетикой, а мат анализом. Нужно собирать статистику об использовании функционала, о скорости заполнения формы и делать это автоматически, не полагаясь полностью на мнение пользователей.
Опять же — ничто не ново под луной.
Спольски писал об этом в 2001, и до него подобные идеи уже были, как я понимаю:
www.joelonsoftware.com/articles/fog0000000012.html
Здесь есть на русском:
www.books.ru/books/dzhoel-o-programmirovanii-fail-pdf-651529/?show=1
Спольски писал об этом в 2001, и до него подобные идеи уже были, как я понимаю:
www.joelonsoftware.com/articles/fog0000000012.html
Здесь есть на русском:
www.books.ru/books/dzhoel-o-programmirovanii-fail-pdf-651529/?show=1
Для разработки интерфейсов подключаются люди (не программисты) которые проектируют этот самый интерфейс.
Всегда спрашиваю дизайнеров или пользователей удобно пользоваться продуктом или нет.
Как программист скажу, что порой связи в БД, между полями формы бывают настолько «хитрыми», что пользователя принудительно приходится ограничивать.
Всегда спрашиваю дизайнеров или пользователей удобно пользоваться продуктом или нет.
Как программист скажу, что порой связи в БД, между полями формы бывают настолько «хитрыми», что пользователя принудительно приходится ограничивать.
Именно так и стараемся действовать, когда заказчик позволяет участвовать в работе Product owner-а. Я уже писала об этом подробнее — есть тут и персоны и еще некоторые инструменты, которые позволяют более глубоко проникнуть в шкуру пользователя. Давай замутим доклад на HappyDev?
UFO just landed and posted this here
Начали за здравие закончили за упокой.
Человек который обосновывает плохие интерфейсы недоразивтием полушарий никогда в промышленой разработке больших проэктов не участвовал, а если и участвовал то вследствие высокой натуры не прочуствовал.
Во первых низашто не поверю что у автора окна на картинке все в порядке с кодом. Боюсь там крошиво из code behind и спагетти кода.
Во вторых уверен что проблема с порталом госуслуг не только в неумении разработчиков. А главная первопричина, что заказчику было наплевать на удобство интерфейса и его тестирование и вся оценка удобства проводилась по наличии интерфейса как такового. Сохранение вводимых данных говорите, это скорее всего непростой функционал который требует значительных усилий(кроме того возникает вопрос безопасности). Давайте угадаю как все случилось: до этапа программирования, бизнес аналитик получил требование что с точки зрения безопасности пользователя нужно выбрасывать из сесии через 15 минут. Хороший аналитик сразу спросит, а что будет с введенными даными, нужно ли их сохранять, потому что хороший бизнес аналитик отвечает за целосность и непротиворечивость бизнес требований. Допустим что наш аналитик даже увидел нужность сохранения данных. Дальше бизнес аналитик выясняет у заказчика, а что с удобством исспользования, а с удобством исспользования заказчик не понимает зачем оно ему и почему он должен за это платить. К тендеру приходим с понимает что чтобы выиграть нужно чем-то пожертвовать, потому пожертвовали «менее» критичным функционалом. Идем дальше, допустим что не пожертвовали, но пропустили по недогляденью, а где же итеративность процеса, развития проэкта. А нету заказчик готов максимум платить за сопровождение и мелкий багфиксинг, а надо будет что-то радикальнее править, так новый тендер и не факт что вы будете победителем. Где здесь роли, где здесь usability? Вопрос риторический. Usability появляется там где есть осознанное желание платить и понимание зачем мне это нужно у заказчика.
В третьих о полушариях. Можно спросить, а вы проводили какой-либо релевантный опрос с целью определить степень способности индивида? Потому что если смотреть оригинальные исследования, то речь шла о большей и меньшей способности индивида к решению определенного вида задач, а не полного неимения таковой, вы ведь не о имбецилах говорим. И программисты прекрасно учатся, особенно при наличии хороших примеров и менторства. Да возможно они не будут вам рисовать как Дали, но как эту формочку с двумя кнопочками расположить поверьте справятся, если им не будет лень и не до этого. Только проблема ведь не в этом, а в том чтобы заказчик (внешний или внутренний) был готов за это платить и понимал что ничего бесплатного не бывает. И 99% проблем с usability происходят из этого. И не стоит к каждому «творческому» заданию лепить уже заезженый штам о полушариях как обоснование.
Человек который обосновывает плохие интерфейсы недоразивтием полушарий никогда в промышленой разработке больших проэктов не участвовал, а если и участвовал то вследствие высокой натуры не прочуствовал.
Во первых низашто не поверю что у автора окна на картинке все в порядке с кодом. Боюсь там крошиво из code behind и спагетти кода.
Во вторых уверен что проблема с порталом госуслуг не только в неумении разработчиков. А главная первопричина, что заказчику было наплевать на удобство интерфейса и его тестирование и вся оценка удобства проводилась по наличии интерфейса как такового. Сохранение вводимых данных говорите, это скорее всего непростой функционал который требует значительных усилий(кроме того возникает вопрос безопасности). Давайте угадаю как все случилось: до этапа программирования, бизнес аналитик получил требование что с точки зрения безопасности пользователя нужно выбрасывать из сесии через 15 минут. Хороший аналитик сразу спросит, а что будет с введенными даными, нужно ли их сохранять, потому что хороший бизнес аналитик отвечает за целосность и непротиворечивость бизнес требований. Допустим что наш аналитик даже увидел нужность сохранения данных. Дальше бизнес аналитик выясняет у заказчика, а что с удобством исспользования, а с удобством исспользования заказчик не понимает зачем оно ему и почему он должен за это платить. К тендеру приходим с понимает что чтобы выиграть нужно чем-то пожертвовать, потому пожертвовали «менее» критичным функционалом. Идем дальше, допустим что не пожертвовали, но пропустили по недогляденью, а где же итеративность процеса, развития проэкта. А нету заказчик готов максимум платить за сопровождение и мелкий багфиксинг, а надо будет что-то радикальнее править, так новый тендер и не факт что вы будете победителем. Где здесь роли, где здесь usability? Вопрос риторический. Usability появляется там где есть осознанное желание платить и понимание зачем мне это нужно у заказчика.
В третьих о полушариях. Можно спросить, а вы проводили какой-либо релевантный опрос с целью определить степень способности индивида? Потому что если смотреть оригинальные исследования, то речь шла о большей и меньшей способности индивида к решению определенного вида задач, а не полного неимения таковой, вы ведь не о имбецилах говорим. И программисты прекрасно учатся, особенно при наличии хороших примеров и менторства. Да возможно они не будут вам рисовать как Дали, но как эту формочку с двумя кнопочками расположить поверьте справятся, если им не будет лень и не до этого. Только проблема ведь не в этом, а в том чтобы заказчик (внешний или внутренний) был готов за это платить и понимал что ничего бесплатного не бывает. И 99% проблем с usability происходят из этого. И не стоит к каждому «творческому» заданию лепить уже заезженый штам о полушариях как обоснование.
Вот вы пишите, что программисты — они не за что не отвечают и обычно тупо пишут что сказали. Я с этим спорить не буду. Возможно в отдельных компаниях так принято. Может быть даже их большинство.
Я не о том сказать хотел: вопрос не в том, что «работает только одно полушарие из двух» а в том, что в проекте у программиста и маркетолога-аналитика-продакта-заказчика (зовите как хотите) принципиально разные ценности. Сам долгое время работал программистом, кроме того, с несколькими десятками девелоперов взаимодействовал в роле ПМа, аналитика, продакта и заказчика. Ага, на вполне крупных промышленных проектах.
И наблюдения чисто статистически показывают: основная ценность для программиста — чёткая, структурированная система без костылей, красивый код, правильная архитектура. Я встречал очень мало программистов, которые готовы принести красивую архитектуру в жертву удобству пользователя, если их прямо не заставить так делать. И это нормально и правильно. Если программист не ценит нормальную архитектуру и красивый код, грош ему цена.
Но есть и другая категория — ПМы, продакты, заказчики, вышедшие из тех же программистов, и по старой памяти ценящие код, архитектуру и внутреннюю строгость системы выше удобства пользователя и общей юзабельности системы. Вот это уже сильно плохо, и это лечить надо. Как раз как тот «заказчик», который по вашей версии зафичекатил сохранение данных в гос. услугах (впрочем, что-то у меня большие сомнения, что такой вопрос вообще поднимался).
В общем, смело можете менять слова «левополушарное мышление» на «особенности логического мышления программиста, связанные с его профессиональной деятельностью», Может быть, так будет проще понять смысл статьи, не отвлекаясь на заезженные штампы
Я не о том сказать хотел: вопрос не в том, что «работает только одно полушарие из двух» а в том, что в проекте у программиста и маркетолога-аналитика-продакта-заказчика (зовите как хотите) принципиально разные ценности. Сам долгое время работал программистом, кроме того, с несколькими десятками девелоперов взаимодействовал в роле ПМа, аналитика, продакта и заказчика. Ага, на вполне крупных промышленных проектах.
И наблюдения чисто статистически показывают: основная ценность для программиста — чёткая, структурированная система без костылей, красивый код, правильная архитектура. Я встречал очень мало программистов, которые готовы принести красивую архитектуру в жертву удобству пользователя, если их прямо не заставить так делать. И это нормально и правильно. Если программист не ценит нормальную архитектуру и красивый код, грош ему цена.
Но есть и другая категория — ПМы, продакты, заказчики, вышедшие из тех же программистов, и по старой памяти ценящие код, архитектуру и внутреннюю строгость системы выше удобства пользователя и общей юзабельности системы. Вот это уже сильно плохо, и это лечить надо. Как раз как тот «заказчик», который по вашей версии зафичекатил сохранение данных в гос. услугах (впрочем, что-то у меня большие сомнения, что такой вопрос вообще поднимался).
В общем, смело можете менять слова «левополушарное мышление» на «особенности логического мышления программиста, связанные с его профессиональной деятельностью», Может быть, так будет проще понять смысл статьи, не отвлекаясь на заезженные штампы
Sign up to leave a comment.
Управление продуктами: Увидеть продукт глазами пользователя