Многие сегодня применяют прототипирование, разрабатывая в самом начале проекта прототипы интерфейсов. Хорошо известно, что исправлении ошибки на этом этапе стоит в разы дешевле, чем на более поздних этапах.
Однако в разработке существует еще один этап, который играет очень большую роль, но которому мало кто уделяет должное внимание. И этот этап — модель проекта в голове, в том числе — интерфейса. И если ошибки на всех других стадиях видны и их легко обнаружить, то ошибка процесса мышления в процессе продумывания проекта и его интерфейса становится понятной только в самом конце — когда проект уже испытывают в боевых условиях.
Как находить ошибки этого рода, бороться с ними, и пример из реальной практики читайте внутри.
Суть ошибки проста. Человек держит в голове представление о каком-либо аспекте мира, и считает, что в реальности так оно и будет. На деле разница между картинкой в голове и действительностью оборачивается сотнями тысяч рублей и десятками часов работы разных специалистов, которые идут в никуда.
Для начала нужно осознать, что сама ошибка существует. Обычно человек уверен, что он может спроектировать интерфейс именно так, как это будет в самом конце, сделать «все правильно» и «все продумать». Но думать так — заблуждение.
Во-первых, все будет изменяться — это закон в разработке любых продуктов. Поэтому чем легче процесс будет поддаваться изменениям — тем лучше. Отсюда правило — делать минимально нужный объем на любом этапе, скажем, итерация в один день — чтобы, если сделано неверное, не жалко было выбросить и сделать сначала.
При этом проверка верности или неверности должна проходить на конечных пользователях продукта, в продукте должны быть живые (а не тестовые) данные, все должно быть реальным.
Во-вторых, нельзя продумать на 100% на начальном этапе. Можно принять за аксиому — если не тот редкий случай, когда проектировщик интерфейса или разработчик концепции проекта имеет глубокий опыт в сфере проекта, в 99% случаев все сложные фишки будут мимо.
Единственно возможный вариант — вжиться в роль конечного пользователя (делаешь софт для бухгалтеров — стань бухгалтером и смотри на софт, как бухгалтер, как решать задачи с точки зрения бухгалтера, и так далее). Но это требует большого опыта и большого мастерства, а зачастую и времени, что не всегда возможно.
Поэтому разумно стремиться выявлять основные задачи на итерацию из уст конкретных пользователей (при этом отделять сами проблемы от того, как пользователи видят решения — ведь пользователи не профессионалы, в отличие от вас, в разработке проектов).
А сами итерации делать максимально короткими и как можно теснее работать с живыми пользователями, поставляя им проект, пусть и работающий лишь частично, с живыми данными, и внимательно собирая обратную связь, наблюдая за ними.
В качестве примера рассмотрим автоматизацию отдела кадров, которой сейчас я занимаюсь в одной компании, работая с командой отличных профессионалов. У нас выстроен процесс, где релизы идут каждый день, и каждый день внедряется тот или иной функционал и пробуется на живых пользователях и реальных данных. За счет таких темпов доработки и реально нужные фишки поступают уже на следующей день.
Так, когда мы сделали автоматизацию учета резюме (все резюме, поступающие на почту и т.д., от девочки, которая их ищет и добавляет руками, и добавляемые через сайт), разбили по статусам (визуально вкладки — не рассмотрено, подумать, выслан тест, отказано, отказались, и т.д.), там в процессе переноса резюме из одной вкладки в другую появлялся попап — куда перенести.
После переноса человека перекидывало на конечную вкладку (находился, к примеру, в «не рассмотрено», выбирал человека, нажимал переместить в «отказано», вводил причину отказа — и его перекидывало в «отказано»). При запуске оказалось, что когда сотрудники отдела кадров разбирают сотни резюме, им удобнее оставаться в текущей вкладке — ибо приходилось, после того как тебя перенесло в конечную вкладку, возвращаться в ту, где ты разбирал список резюме.
Если бы проектировщик поработал с сотней резюме, а не десятком, решая реальную задачу, он бы не допустил этой ошибки. Ее исправление стоило пары часов работы программиста, а их могло бы и не быть. Также и с фильтром по ФИО — если бы человек попробовал работать с 1000 резюме, он бы понял, что фильтр по ФИО очень необходим.
Собственно, многие стартапы оказываются ненужными потому, что люди считают
себя умнее своих пользователей, и создают никому не нужные интерфейсы, движки и проекты, тратя свое время и деньги (а зачастую не только свое).
Стоит заметить, что этот подход является паттерном в широком смысле слова. Это значит, что его можно применить в любой сфере. Например, в программировании — получить ТЗ от заказчика, набросать прототип, верный с точки зрения логики, но в коде «как быстрее». Показать тут же, получить список доработок, и так до тех пор, пока основная логика не будет сделана. Дальше отрефакторить, и сделать уже точно. Такой подход позволит сэкономить от 100% до 1000% вашего времени, и времени заказчика.
Желаю вам, чтобы в ваших проектах процент нужного функционала стремился к 100%!
Однако в разработке существует еще один этап, который играет очень большую роль, но которому мало кто уделяет должное внимание. И этот этап — модель проекта в голове, в том числе — интерфейса. И если ошибки на всех других стадиях видны и их легко обнаружить, то ошибка процесса мышления в процессе продумывания проекта и его интерфейса становится понятной только в самом конце — когда проект уже испытывают в боевых условиях.
Как находить ошибки этого рода, бороться с ними, и пример из реальной практики читайте внутри.
Суть ошибки проста. Человек держит в голове представление о каком-либо аспекте мира, и считает, что в реальности так оно и будет. На деле разница между картинкой в голове и действительностью оборачивается сотнями тысяч рублей и десятками часов работы разных специалистов, которые идут в никуда.
Для начала нужно осознать, что сама ошибка существует. Обычно человек уверен, что он может спроектировать интерфейс именно так, как это будет в самом конце, сделать «все правильно» и «все продумать». Но думать так — заблуждение.
Во-первых, все будет изменяться — это закон в разработке любых продуктов. Поэтому чем легче процесс будет поддаваться изменениям — тем лучше. Отсюда правило — делать минимально нужный объем на любом этапе, скажем, итерация в один день — чтобы, если сделано неверное, не жалко было выбросить и сделать сначала.
При этом проверка верности или неверности должна проходить на конечных пользователях продукта, в продукте должны быть живые (а не тестовые) данные, все должно быть реальным.
Во-вторых, нельзя продумать на 100% на начальном этапе. Можно принять за аксиому — если не тот редкий случай, когда проектировщик интерфейса или разработчик концепции проекта имеет глубокий опыт в сфере проекта, в 99% случаев все сложные фишки будут мимо.
Единственно возможный вариант — вжиться в роль конечного пользователя (делаешь софт для бухгалтеров — стань бухгалтером и смотри на софт, как бухгалтер, как решать задачи с точки зрения бухгалтера, и так далее). Но это требует большого опыта и большого мастерства, а зачастую и времени, что не всегда возможно.
Поэтому разумно стремиться выявлять основные задачи на итерацию из уст конкретных пользователей (при этом отделять сами проблемы от того, как пользователи видят решения — ведь пользователи не профессионалы, в отличие от вас, в разработке проектов).
А сами итерации делать максимально короткими и как можно теснее работать с живыми пользователями, поставляя им проект, пусть и работающий лишь частично, с живыми данными, и внимательно собирая обратную связь, наблюдая за ними.
В качестве примера рассмотрим автоматизацию отдела кадров, которой сейчас я занимаюсь в одной компании, работая с командой отличных профессионалов. У нас выстроен процесс, где релизы идут каждый день, и каждый день внедряется тот или иной функционал и пробуется на живых пользователях и реальных данных. За счет таких темпов доработки и реально нужные фишки поступают уже на следующей день.
Так, когда мы сделали автоматизацию учета резюме (все резюме, поступающие на почту и т.д., от девочки, которая их ищет и добавляет руками, и добавляемые через сайт), разбили по статусам (визуально вкладки — не рассмотрено, подумать, выслан тест, отказано, отказались, и т.д.), там в процессе переноса резюме из одной вкладки в другую появлялся попап — куда перенести.
После переноса человека перекидывало на конечную вкладку (находился, к примеру, в «не рассмотрено», выбирал человека, нажимал переместить в «отказано», вводил причину отказа — и его перекидывало в «отказано»). При запуске оказалось, что когда сотрудники отдела кадров разбирают сотни резюме, им удобнее оставаться в текущей вкладке — ибо приходилось, после того как тебя перенесло в конечную вкладку, возвращаться в ту, где ты разбирал список резюме.
Если бы проектировщик поработал с сотней резюме, а не десятком, решая реальную задачу, он бы не допустил этой ошибки. Ее исправление стоило пары часов работы программиста, а их могло бы и не быть. Также и с фильтром по ФИО — если бы человек попробовал работать с 1000 резюме, он бы понял, что фильтр по ФИО очень необходим.
Собственно, многие стартапы оказываются ненужными потому, что люди считают
себя умнее своих пользователей, и создают никому не нужные интерфейсы, движки и проекты, тратя свое время и деньги (а зачастую не только свое).
Стоит заметить, что этот подход является паттерном в широком смысле слова. Это значит, что его можно применить в любой сфере. Например, в программировании — получить ТЗ от заказчика, набросать прототип, верный с точки зрения логики, но в коде «как быстрее». Показать тут же, получить список доработок, и так до тех пор, пока основная логика не будет сделана. Дальше отрефакторить, и сделать уже точно. Такой подход позволит сэкономить от 100% до 1000% вашего времени, и времени заказчика.
Желаю вам, чтобы в ваших проектах процент нужного функционала стремился к 100%!
