Дизайн-мышление в заказной разработке

30.06.22

Архитектура

Метод дизайн-мышления смещает приоритеты разработки на потребности пользователя. Но как понять, что пользователь хочет и учесть его подразумеваемые требования? О том, как с помощью эмпатии к пользователю и визуализации идей сделать удобный для заказчика продукт, в докладе на Infostart Event 2021 Moscow Premiere рассказала Мария Серёгина.

Меня зовут Мария Серегина, с 2014 года я занимаюсь работой с 1С в различных аспектах.

За это время поработала и консультантом, и в службе технической поддержки. Продавала доработки для 1С, занималась тестированием, руководила двумя подразделениями – это была линия технической поддержки и отдел сопровождения в 1С-франчайзи.

Сейчас я работаю бизнес-аналитиком в группе компаний Арбис, в центре облачных решений.

 

Дизайн-мышление как способ работать с требованиями

 

Для начала я коротко расскажу о том, что же такое дизайн-мышление, и почему мы на секции «ИТ-анализ» вдруг начинаем о нем говорить.

Дизайн-мышление – это способ подходить к работе с требованиями к программному обеспечению с точки зрения эмпатии к пользователю и его потребностям.

При этом мы изначально слегка отходим от стандартной схемы:

  • меньше думаем о технологии;

  • меньше думаем о том, какой у нас есть бюджет, если это фикс-прайс, например;

  • меньше думаем о бизнес-целях заказчика.

У нас идет непосредственная фокусировка на пользователе, на том, какой пользовательский опыт он получит.

Про этапы метода дизайн-мышления уже подробно рассказал в своем докладе Алексей Таченков.

Если коротко, этапов всего шесть. Каждый этап включает в себя сбор информации и ее обработку.

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

  • Следующий этап – это фокусировка. На этом этапе мы стараемся найти какой-то один ключевой вопрос. Их может быть несколько. Я сейчас не говорю о том, что мы должны один вопрос взять, а остальные выбросить. Мы просто сосредотачиваемся на каком-то одном вопросе, который мы хотим решить в данный момент, и пытаемся сформулировать этот вопрос. Алексей Таченков рассказывал про инструмент, который называется point of view (либо «точка зрения», если по-русски). Точка зрения представляет собой формулировку, в которой мы рассказываем, над чем в дальнейшем нам нужно будет работать. То есть мы формулируем вопрос, как мы можем помочь некоему пользователю или группе пользователей выполнить ту или иную задачу и задаем какой-то критерий – быстро и эффективно, с минимальным количеством затрат, без звонка в службу технической поддержки.

  • Дальше, когда у нас уже сформирована «point of view» , мы приступаем к генерации идей. Процесс генерации идей основан на нашей точке зрения. То есть, мы не просто генерируем идею, считая, что нужно добавить какую-то прикольную фичу, все наши идеи должны быть привязаны к тому вопросу, который мы сформулировали. Мы можем написать этот вопрос на бумаге, приклеить на стену и вокруг него клеить стикеры с идеями, можно сделать доску в Miro, и фиксировать вопрос и идеи там. Можно просто на любой канбан-доске накидывать карточки. Самое главное – не отходить далеко от этого вопроса, который мы начали решать и набрать максимальное количество идей, пусть они будут, возможно, сейчас не реализуемыми, слишком дорогими, слишком амбициозными. Но пусть они будут. Это в дальнейшем вам позволит мыслить более масштабно, и, возможно, запланировать вторую-третью итерацию вашего проекта.

  • Выбор идеи. Это момент, когда начинается приоритезация. Когда мы начинаем делать приоритезацию, самое важное – это определить критерии. По какому критерию мы будем отбирать наши идеи? Возможно, это должна быть идея, которую мы реализуем максимально быстро. Или максимально дешево. Или это какое-то ноу-хау, такого никто не делал. Все эти критерии мы для себя определяем, он может быть один, их может быть несколько. И сортируем наши идеи в соответствии с обозначенными критериями. Дальше работаем с теми идеями, которые набрали наибольший приоритет.

  • Этап прототипирования. Я слышала, что по прототипированию были вопросы. Я сегодня буду подробно о нем рассказывать. Прототипировать можно, это можно делать очень красиво, и потом это красивое показывать заказчику. Эти удивительные технологии у нас появились благодаря отделу веб-разработки, который есть у нас в компании. Эти замечательные люди поделились тем, как они готовят прототипы для своих решений, поэтому мы теперь можем красиво прототипировать 1С.

  • Этап тестирования – здесь имеется в виду именно тестирование прототипа. Мы на этот момент не готовим никакой MVP, ничего не делаем, у нас есть только прототип, только картинки.

 

Этап эмпатии – сбор требований

Поговорим подробнее про этап эмпатии.

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

Но если мы заступаем в какую-то новую предметную область, или у нас по бизнес-процессу появляется какой-то новый пользователь, нам нужно достаточно хорошо понять – кто он, какие перед ним стоят задачи, как он приходит к работе с этой функциональностью? Есть ли у него какая-то предварительная подготовка или мы должны в нашей функциональности предусмотреть какие-нибудь подсказки, чтобы его сориентировать. Всю эту информацию о пользователе нам нужно собрать.

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

 

Что же делать, когда такой возможности нет?

Предположим, у нас есть только представитель заказчика. У меня так очень часто бывает на проекте – с конечными пользователями вижусь очень редко. Чаще всего, мы контактируем с ними только тогда, когда у них возникают проблемы. Соответственно, если у нас есть контакт только в виде представителя заказчика, наша задача – сформулировать вопросы таким образом, чтобы заказчик включился в процесс исследования пользователей, чтобы ему захотелось рассказать о каждом из своих сотрудников. Например, о том, что вот этот пользователь в программе должен делать вот это и вот это, а еще иметь возможность вот это посмотреть. А еще они говорят, что им вот это очень не нравится. А вчера пришло письмо – они жаловались, что это очень неудобно. Соответственно, нам нужно всю эту информацию собрать. Возможно, на этапе решения конкретно этой задачи вам эта информация ничего не даст, но у вас появится полноценный портрет вашего пользователя, с помощью которого вы сможете следующие проекты реализовывать уже более эффективно. Потому что вам не придется слишком много времени затрачивать на исследования, на поиск того, что пользователям нравится или не нравится в текущем продукте. Вы сможете просто дополнять образ вашего пользователя.

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

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

Третье – интересуемся не только своей точкой зрения. Например, на некоторых этапах бизнес-процессов есть конкретные моменты, когда пользователи говорят: «Это неудобно, это непонятно, это неинтуитивно – я не знаю, куда нажимать». В этом случае поможет звонок в службу поддержки, поиск инструкции, вызов специалиста, чтобы приехал, кнопочку нажал. Все эти моменты нужно воспринимать открыто. Даже если та функциональность, которая сейчас существует, – не наших рук дело, нужно не бояться услышать эту критику в свой адрес. И пробовать переосмыслить. А может быть, действительно, неудобно. А как можно сделать удобнее? Это – такой путь постоянного развития, постоянного совершенствования, поэтому информацию о том, что неудобно, некомфортно, собираем в первую очередь.

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

Еще один момент относительно пожеланий пользователей, которые могут у вас появиться.

  • Есть потребности – это те моменты, которые обусловлены бизнес-процессами, которые обусловлены законодательством, то, от чего мы никак не можем отказаться.

  • И есть пожелания пользователей: «Хотелось бы, чтобы было быстрее. Хотелось бы, чтобы было удобнее. Хотелось бы меньше кнопок нажимать».

Все эти моменты очень хорошо иллюстрирует модель Кано.

Модель Кано прямого отношения к дизайн-мышлению не имеет, но очень сильно помогает не упустить из поля зрения некоторые моменты.

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

Потому что, если мы, например, зашли в какую-то новую предметную область, для нас эти «подразумеваемые требования» пока скрыты. Поэтому мы стараемся процесс изучить досконально. Можно даже визуализировать и посмотреть – вот здесь у меня требования понятны, мне вот это все рассказали. А вот здесь – почему пусто?

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

Помимо подразумеваемых требований, есть также «Неосознанные требования» – те самые, которые производят вау-эффект. Пользователь не ожидал, что получится так быстро, а мы сделали. Он не думал, что получится настолько легко, а у нас получилось. Он не думал, что 1С может быть интуитивно понятной, а она вдруг стала интуитивно понятна: еще и какую-то подсказку дала, и все здорово, классно получилось. И вообще, 1С уже не такая плохая.

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

При этом, если вы упустите область неосознанных требований, ничего страшного не произойдет – ваш пользователь просто получит классный продукт, который решит его задачу. Но если мы упустим высказанные требования, либо мы упустим требования подразумеваемые, то тут дело будет плохо.

 

Фокусировка – формулирование точки зрения

 

Когда у нас все эти требования собраны, мы готовимся формулировать точку зрения.

Коротко расскажу об одном кейсе.

Я работаю с облачным сервисом 1С, и в этом облачном сервисе у каждого главного бухгалтера есть своя рабочая группа из бухгалтера и оператора по вводу данных. При этом у рабочей группы может быть огромное количество клиентов, а может быть, наоборот, только два клиента. Соответственно, тот продукт, который мы выпускаем, должен удовлетворять и того главного бухгалтера, у которого два клиента, и того, у кого этих клиентов 100.

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

Когда я сформулировала эту точку зрения, мне казалось, что все здорово, что я все поняла – классно, будем проверять наличие непроведенных документов.

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

Поэтому в дальнейшем точка зрения дополнилась, и у нас появился еще запрос на то, чтобы каким-либо образом эти непроведенные документы помечать, чтобы видеть, какие непроведенные документы действительно такими и должны быть, а из-за каких нам нужно идти в базу и с ними разбираться.

 

Генерация идей

 

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

Мне повезло, у меня была возможность коммуницировать с моим менеджером. Поэтому я придумывала какую-нибудь идею, бежала к ней и говорила: «Смотри, вот такая идея, что ты об этом думаешь?» Вот это – очень важный момент. Взять обратную связь хоть у кого-нибудь, чтобы не застрять на одной мысли, чтобы получить толчок для ее развития. Если нам скажут: «Да, прикольно, а еще вот так можно.» это нужно записать и действительно над этим подумать. Или, если скажут: «Нет, это неудобно», в этот момент нужно не грустить и уходить, а пытаться уточнить, что именно показалось неудобным, а как можно было бы еще сделать? Этот этап можно реализовывать не только в очень большой команде, но и просто, находя коллегу, который готов дать фидбек по вашему решению.

Также очень здорово консультироваться у разработчиков. Не знаю, насколько вовлечены в процесс проектирования разработчики в разных командах, но нам, наверное, повезло, у нас разработчики очень любят делиться своим мнением. Точка зрения разработчика очень классная. Она не всегда ориентирована на пользователя, но она помогает увидеть продукт с двух сторон. И со стороны пользователя, и со стороны технического решения. Мы сможем иметь в виду, что в дальнейшем с нашим решением произойдет, иметь понимание по технической части тоже очень важно на этапе проектирования.

Консультация со службой поддержки. Это вообще супер. Если вы были на предыдущей лекции, Алексей нам показывал карту эмпатии. Здесь информация от службы поддержки бывает очень и очень полезна, потому что это те люди, которые как раз работают с эмоциями пользователя, это им достается звонок: «У меня ничего не работает, я ничего не понял, почините все, как было, откатите на предыдущую версию, она была круче». Соответственно, мы в службе поддержки можем всю эту информацию собрать, систематизировать и дополнить нашу картину мира, тем самым предотвратить реализацию заведомо неудобного интерфейса или заведомо сложного логически решения.

Если у вас есть коллега-аналитик – это вообще классно. Тогда у вас появляется единомышленник, с которым вы можете на одном уровне видения проектирования и интерфейса, и логики обсудить все. Если время позволяет, можно устроить полноценный мозговой штурм. Старайтесь максимально в этот процесс вовлечь коллег. Даже если вы не работаете по классике, по дизайн-мышлению, по всем шести этапам, вы можете спокойно брать какой-то один этап. Например, вам не хватает идей – подключайте коллег. Почему нет? Это просто инструмент, который позволяет вам научиться работать командно и творчески.

 

Визуализация идей

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

Когда мы начинаем рисовать, мы берем идею, которую мы придумали – она может на тексте казаться очень крутой. Но когда мы ее отрисуем, мы начинаем понимать – нет, что-то как-то очень сложно, что-то как-то очень много кнопок нужно нажать. Какая-то форма уже перегруженная, текста многовато. И с помощью таких картинок мы можем составить целый сценарий. Мы можем, например, обратиться к тому же инструменту Customer Journey Map, либо есть еще второй вариант User Journey Map. Инструменты, в принципе, одинаковые, и они нам позволяют проследить путь пользователя. И мы можем прототипы наложить на вот этот путь. Например, пользователь запускает какую-то подсистему, дальше – что-нибудь загружает, что-нибудь проверяет. Мы идем по этому пути и проверяем, везде ли у нас все комфортно, везде ли у нас все продумано, на все ли у нас хватает кнопочек.

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

Вот он, красивый вариант. Этот прототип нарисован в Figma.

Figma – это тот инструмент, который очень часто используют для веб-разработки, но, на самом деле, он очень удобен и для задач по проектированию интерфейсов 1С.

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

Для демонстрации – понятно, это просто выглядит эффектно. Как будто у нас уже готовая программа, и мы показываем ее возможности. А на этапе тестирования очень удобно проверять, а правильно ли мы поняли, что такое решение интуитивно понятное. Т.е. мы можем дать пользователю какую-то задачу – это, кстати, можно делать онлайн, не обязательно выезжать, можно просто отправить ссылку и попросить выполнить какое-нибудь действие. Например, мы просим пользователя отключить некоторые документы, чтобы по ним не приходили оповещения. И если пользователь нажимает в нужную область, у него все получается, и открывается следующий экран. Если он нажимает куда-то не туда, соответственно, просто он дальше не пойдет, и мы получим информацию о том, что наше решение не интуитивное, с этим нужно что-то делать.

 

Прототипирование

Относительно создания прототипов нужно помнить следующее:

  • прототип – не конечный вариант, а просто один из вариантов;

  • он нам позволяет получить обратную связь, с помощью которой мы сможем наш интерфейс доработать и уже в разработку передать продуманное готовое решение.

Эти прототипы мы показываем не только нашему заказчику, с ними работают и разработчики. Это позволяет нам сконнектиться не только на уровне требований, но и на уровне визуала. Когда разработчик видит, как будет выглядеть форма, у него появляется меньше вопросов к ней. Мы видим продукт одинаково. Также это помогает тестировщикам. Тестировщики тоже могут на эти прототипы посмотреть, и суть того или иного технического проекта мы им рассказываем на прототипах: «Посмотри, будут заложены вот такие функции – ознакомься с требованиями. Если будут возникать вопросы, обращайся».

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

 

Этап тестирования

 

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

Хочется, чтобы понравилось, но далеко не всегда так происходит. Иногда заказчик говорит: «Нет, я совсем не это имел в виду».

Тут нужно порадоваться тому, что у нас появилась точка роста, с помощью которой мы можем понять ход мыслей заказчика, понять, что ему нравится, а что – не нравится. Соответственно, мы можем сделать наше взаимодействие более эффективным.

 

Заключение

 

 

И в заключение хочу немного отойти от темы бизнес-анализа, дизайн-мышления и рассказать вам про удивительную книгу от издательства «МИФ», Адам Грант, «Подумайте еще раз». Она рассказывает о том, что как бы высоко мы не забирались, нужно оставаться открытыми к изменению своей точки зрения.

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

Но в дальнейшем у нас либо может сильно подрасти уверенность, но не подрасти компетентность – тогда мы превращаемся в так называемых «диванных критиков» со своим жестким мнением обо всем.

Либо мы можем нарастить свою экспертность, но не нарастить свою уверенность. Тогда мы можем стать людьми с синдромом самозванца. Сейчас это тренд.

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

 

Вопросы

 

Когда вы делали прототип для Figma, вы сначала отрисовывали формы в 1С, а потом скопировали в Figma?

Нет, это сделано с помощью UI Kit. В принципе, UI Kit с 1С-ными кнопочками и формами есть в открытом доступе в интернете, но у нас коллеги подготовили собственный UI Kit, он представляет собой некоторый набор 1С-ных элементов, которые мы просто можем, как конструктор, собирать.

Как справляетесь со следующими пользователями, которые говорят: «Я работал в СБИС, там все очень удобно. Отрисуйте мне акт, платежное поручение в 1С так же, как в СБИС. А еще сделайте мне четыре аналитики – такие же, как были у меня в СБИСе». Как вы на это реагируете? Идете рисовать в Figma? Или переубеждаете как-то пользователя?

С переубеждением мы в принципе не работаем. Раньше я работала, действительно, и с такими запросами, но там все было очень индивидуально, иногда, например, оказывалось, что просто нравится какая-то определенная фишка из СБИСа, и мы можем попробовать просто ее как-то интегрировать в существующую функциональность. Очень редко бывает такое, что нравится вообще все, и нужно сделать все один в один. Здесь нужно больше вступить в диалог и понять, а что именно им кажется удобным, и чего не хватает у нас. Например, у меня недавно был такой запрос – попросили сделать систему оповещения точно такую же, как в СБИСе. Понятно, что мы такого сделать не можем, но мы можем сделать аналог, если мы узнаем какие-то ключевые моменты, которые понравились в СБИСе. Это как раз такой момент для проработки себя как интервьюера – разговорить человека и выявить его истинную потребность – чего ему не хватает.

Вы же наверняка сравнивали Figma с конфигуратором? В чем преимущество Figma для работы именно аналитиков? Именно в части прототипирования форм? Ведь работе в Figma тоже нужно учиться, плюс есть вот эти UI Kit-ы, которые нужно использовать? Чем это лучше? Поделитесь опытом использования.

Если честно, я ни разу в жизни не пробовала прототипировать в конфигураторе, я вообще с конфигуратором очень мало взаимодействовала, разве что на старте, когда еще работала техническим специалистом. Удобно это тем, что у вас в проектировании может участвовать человек, который в принципе не имеет большого бэкграунда работы именно с конфигурацией. Достаточно базового понимания того, что можно в 1С реализовать, а что нельзя. Это очень удобно, потому что ниже порог вхождения, чтобы начать прототипировать.

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Moscow Premiere.

 

Приглашаем на конференции Инфостарта 2025 года

INFOSTART TEAMLEAD EVENT

Не только для разработчиков, но и для руководителей отделов разработки, тимлидов и ИТ-директоров.
Место: Москва
Даты: 24-25 февраля 2025 г.

Подробнее

INFOSTART A&PM EVENT (Анализ & Управление проектами)

Практическая конференция для аналитиков и руководителей проектов 1С.
Место: Санкт-Петербург
Даты: 29-31 мая 2025 г.

Подробнее


См. также

Кейсы автоматизации Платформа 1С v8.3 1С:Документооборот Бесплатно (free)

Компания «Уралхим» использует 1С:Документооборот не только для хранения и согласования документов, но и для централизованного управления НСИ между 47 системами (не только на 1С); для бэкенда к мобильным приложениям охранников; и в качестве сервиса заказа справок для сотрудников. О деталях реализации нестандартных решений, разработанных в компании «Уралхим» на базе 1С:Документооборот, пойдет речь в статье.

02.08.2024    3176    0    Novattor    1    

16

Кейсы автоматизации Платформа 1С v8.3 Энергетика и ЖКХ Россия Бесплатно (free)

Делимся опытом автоматизации учета башни раздачи воды.

27.12.2023    2064    0    slavik27    5    

15

Отчеты и дашборды Бизнес-аналитик Бухгалтер Пользователь Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Если вы привыкли выгружать бухгалтерские операции в Excel и дополнять их там управленческой информацией, вы сможете значительно сэкономить время, получая нужные управленческие отчеты в бухгалтерской программе сразу, без лишних движений. Представляем решение для самостоятельного внедрения управленческого учета в 1С:Бухгалтерии.

11.12.2023    2740    0    Serg_Tangatarov    2    

16

Архитектура решений Программист Бесплатно (free)

Рассмотрим применение архитектурной проверки задач в процессе разработки.

30.10.2023    5242    0    ivanov660    10    

34

Кейсы автоматизации Работа с требованиями Анализ бизнес-процессов Бесплатно (free)

Автоматизировать производственные процессы в 1С:ERP без доработки типовых механизмов очень сложно. А дорабатывать типовые механизмы 1С:ERP не всегда оправданно. Решением может стать технология разработки Рабочих мест, которая позволяет автоматизировать самые сложные участки последовательно – шаг за шагом, процесс за процессом. Расскажем о том, как помочь пользователям вводить большое количество данных, не нарушая порядок ввода и полноту заполнения всех необходимых реквизитов, и как вовлечь сотрудников Заказчика в разработку и тестирование функционала Рабочих мест.

26.10.2023    2695    0    user1754524    15    

17

Кейсы автоматизации Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Когда проект внедрения ERP в крупном холдинге захлебывается в проблемах производительности и в отчаянии пользователей, нужен комплексный подход. Расскажем о битве за производительность и об организационных мероприятиях по наведению порядка в системе и коллективе.

29.08.2023    3405    0    ke_almaty    0    

15

Архитектура Рефакторинг и качество кода Обновление 1С Программист Стажер Платформа 1С v8.3 Бесплатно (free)

Нашей компании часто приходится сталкиваться с обновлением конфигураций разной степени переписанности. Какие-то из них обновляются легко, какие-то — не очень. Расскажем о некоторых принципах модификации программы, которые помогут сделать последующий процесс обновления легче. Или тяжелее, если стараться их не соблюдать.

10.08.2023    10916    0    1c-izh    37    

23
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. starik-2005 3080 30.06.22 13:28 Сейчас в теме
Он не думал, что получится настолько легко, а у нас получилось.
Он начал думать, что все легко, стал диванным футболистом экспертом, а разработчик получил синдром самозванца.

Вот вам физическое противоречие, чисто так по ТРИЗ Альцшуллера. И что будет с ним делать, как преодолевать? Вау-эффекты при такой работе сразу же закончатся, к вам запрыгнут на хребет и начнут загонять...
2. SerjoginaMaria 87 30.06.22 14:05 Сейчас в теме
(1) Диванные эксперты могут появиться в любой момент, вне зависимости от того, как мы подходим к решению задачи.

Получит разработчик синдром самозванца или нет - зависит от множества факторов.

Вау-эффекты далеко не всем нужны, это скорее исключение.

Как и любой другой метод, дизайн-мышление надо применять там, где оно уместно и решает задачу. Так же, как и ТРИЗ :)
3. starik-2005 3080 30.06.22 14:32 Сейчас в теме
(2) А на вопрос ответить?
4. SerjoginaMaria 87 30.06.22 14:37 Сейчас в теме
(3) Синдром самозванца у разработчика - это зона ответственности самого разработчика. Каждый сам выбирает как себя ощущать :)

Рекомендую книгу с последнего слайда, там всё хорошо объясняется.
5. starik-2005 3080 30.06.22 17:12 Сейчас в теме
(4) Вопрос был:
И что будет с ним делать, как преодолевать?
И "ними" - это множественное число.
6. SerjoginaMaria 87 30.06.22 17:16 Сейчас в теме
(5) Я не практикую работу по ТРИЗ :) Мой доклад был про дизайн-мышление, его можем обсудить. Пока не очень понимаю в чём суть вопроса.
7. starik-2005 3080 30.06.22 20:22 Сейчас в теме
(6)
Он не думал, что получится настолько легко, а у нас получилось.
Вот о проблемах этой легкости, за которой может последовать когнитивное искажение с обоих сторон.
10. SerjoginaMaria 87 01.07.22 17:25 Сейчас в теме
(7) Работа с когнитивными искажениями - это отдельная большая тема. Пытаться их предотвратить, жертвуя удобством для пользователя, не лучший вариант.
8. PLAstic 296 01.07.22 10:19 Сейчас в теме
И сейчас все такие программеры с 20+ лет стажа в 1С аж присели... Всё это время (раз за 20 лет они не умерли, а развились во вполне себе ведущих разработчиков или руководителей отделов разработки) они применяли обычный здравый смысл - чтобы сделать оптимально, надо понять истинную причину задачи. А тут вдруг кто-то обнаружил, что это "дизайн-что-то-там". Это как масса мемов про Малыша и Карлсона, когда он обычные вещи называет разными модными словами. :)
В любом случае, рад, что обычный здравый смысл при приёмке задачи кому-то помогает быть более эффективным.

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

Ещё есть релакс-мышление - это когда думаешь про какую-нибудь задачу пока валяешься в кровати перед сном и тут вдруг осеняет, вскакиваешь и конспектируешь, чтобы не забыть.
starik-2005; +1 Ответить
9. starik-2005 3080 01.07.22 12:52 Сейчас в теме
(8) в принципе все в мире в чксти описанных систем, подходов и т.д. - это здравый смысл, который кто-то, вскочив с кровати, законспектировал чтобы не забыть. Вот, например, нормальные формы . Я как-то прочитал про них, понял, что ну как бы все дет по пути сокращения инфоомации в ИБ, точнее по пути сокращения дублей. И там сплошной здравый смысл, но ты о нем не особо задумываешься. А потом пртходит некий Уася, Питэр, Вонг - и они все этот здравый смысл, спрыгнув с кровать, конспектируют и предлагают общественности в виде статьи с аргументацией. И не вижу я тут ничкго плохого.

А дизайн-мышление - штука хорошая. Ведь основная проблема - это не попасть в цель, а вообще понять, куда стрелять. Это один из вопросов, при этом заказчику кажется, что если у него его 1 плюс два само посчитается, то это уже какие-то проблемы решит. А дизайн-мышление предлагает дальше посмотреть, чтобы и два к одному прибавить, и прочие суммы посчитать, которые заказяик после этих раз и два будет продолжать считать на калькуляторе. В общем это поиск настоящих целей, а не мнимых местячковых целей заказчика, т.к. он решает трудность здесь и сейчас, а не во вселенной, жизни и вообще. Поэтому он и вопрос толком сформулировать н5 может, поэтому и ответ на этот плохо сформулированный вопрос его не устраивает, хотя он получил именно то, что хотел. Это как с Нюшей из смешариков: "иногда вот что-то хочешь, а как получишь, то и не хочешь уже".

Ну и вообще здравый смысл в систему неплохо запихать, чтобы до всех донести. В этом польза.
mikadi; PLAstic; +2 Ответить
11. SerjoginaMaria 87 01.07.22 17:34 Сейчас в теме
(8) Про дизайн-мышление начали рассказывать еще в 1969 году. Если "программеры с 20+ лет стажа" о нём не слышали, это не значит, что оно не существовало. :)

Здравый смысл у каждого индивидуален, его нельзя передать другому. Метод дизайн-мышления пошагово описан, поэтому его могут применять разные люди, достигая ожидаемых результатов. Если где-нибудь появится пошаговое описание применения здравого смысла, тогда можно будет говорить о том, что с его помощью можно быть более эффективным. :)
12. starik-2005 3080 04.07.22 09:06 Сейчас в теме
(11) ТРИЗ, например, является пошаговым определением "здравого смысла". Правда без лекции о ТРИЗ достаточно сложно прийти к этим выводам, но зато потом думаешь: "да, один сплошной здравый смысл".
По поводу дизайн-мышления, то вот:
Идею дизайн-мышления сформулировал Герберт Саймон в 1969 году в книге «Науки об искусственном». Позднее учёные Станфордского университета развили её и основали Stanford d.school — «место для исследователей и экспериментаторов», которое популяризирует этот подход.
Программисты тут ни при чем. По поводу ТРИЗ, то вот:
Первая версия ТРИЗ была разработана советским инженером-изобретателем Генрихом Альтшуллером, который работал в патентном бюро и там проанализировал 40 тысяч патентов в попытке найти закономерности в процессе решения инженерных задач и появления новых идей. Работа над ТРИЗом была начата Альтшуллером в 1946 году, первая публикация была выпущена им и Рафаэлем Шапиро в 1956 году[2].
Программисты ни при чем снова.
13. Petr54-ru 92 13.07.22 05:57 Сейчас в теме
По поводу прототипирования, в случае разработки на 1С УФ, в докладе предлагается совершать не дешевые лишние движения. Поясню.

В процессе проектирования информационной системы, мы в первом приближении получим:
0. Концепцию решения;
1. Фичлист - описание функционала решения;
2. Структуру данных;
3. Нужные нам объекты конфигруации, для работы с полученными данными;
4. Сценарии действий пользователей (кому надо, рисуют DFD-диаграммки).

Вот после этого, есть смысл согласовывать интерфейсы.

Дальше я что обычно делаю. По-быстрому добавляю в конфигуратуре нужные объекты конфигурации, затем в конфигураторе этим объектам рисую формы - вот оно и прототипирование. Я сомневаюсь, что трудоемкость делания этого при помощи отдельного инструмента + перенос этого в конфигуратор ниже, чем просто нарисовать это в конфигураторе сразу (конечно про 1С УФ речь).

Понятно,что в процессе согласования интерфейсов, обязательно повылазят невиданные доселе хотелки, и в пункты 0-4 будут внесены изменения. Но трудозатраты внесений изменений в конфигурацию на этом этапе - копеечные.

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

Есть еще один философский вопрос - кто должен проектировать пользовательские интерфейсы - инженер по интерфейсам или главный бухгалтер? Мне пришлось как-то давно работать в таком проекте, где UI был отдан на откуп главному бухгалтеру. Заказчик был удовлетворен, но эту разработку в таком виде никому показывать было нельзя, и думать о бедолагах операторах, которым пришлось потом в этом работать не хотелось.

В эту тему есть еще один занятный на мой взгляд, вопрос по подходам к проектированию GUI для автоматизации бизнеса. Был неплохой фильм "Багровые реки", Жан Рено в главной роли. Действо происходит во французской глубинке, герои приходят в вагончик бытовку французской дорожной компании и пожелали получить данные из базы по ДТП. В вагончике стоял юниксовый терминал с командной строкой, и сторож оперативно, в командной строке sql запросом дернул нужные данные из базы. Ну и как бы вопрос - что было бы выгодно гипотетической дорожной компании - Нарисовать гуевый интерфейс к своей базе, заменить везде дешманские терминалы на PC и обучить персонал работе в этом GUI или же научить персонал нужному минимуму работы с командной строкой? Обычно люди на этот вопрос отвечают - нужно рисовать GUI, менять компы - потомучто это прогресс, это новое.

Что касается остального доклада, в основе то, что в компании моих друзей называется - "технологиями допросов" в рамках выполнения предпроектных работ и сбора требований. Тема сама по себе глобальная. В рамках доклада вообще не раскрыта тема политики. Это про что написано в классической книжке Эдварда Йордана "Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте". По моим оценкам, вес политики в проектах автоматизации 25-35%. Фактор очень серьезный.
starik-2005; PLAstic; +2 Ответить
14. PLAstic 296 18.07.22 10:41 Сейчас в теме
(13)
классической книжке Эдварда Йордана "Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте"

О!!! Рад, что не только я читал эту книгу. Древняя книжечка так-то. :)
Petr54-ru; +1 Ответить
15. Petr54-ru 92 19.07.22 05:20 Сейчас в теме
(14)
О!!! Рад, что не только я читал эту книгу. Древняя книжечка так-то. :)


А есть какие-то свежие книжки про политику в области выполнения ИТ-проектов?

Есть правда отечественная книжка Андрея Орлова "Записки автоматизатора, профессиональная исповедь", он там в том числе и по теме политики прошелся.

С моей точки зрения упомянутая мной книжка Эдварда Йордана - это классика из разряда "must read". Наш бизнес это в основном работа с людьми, а люди почти не изменились за это время. Мне приходилось по работе попадать в замесы связанные с политикой, и понимание процессов подчерпнутое в этой книжке не раз выручало.
Оставьте свое сообщение