Pull to refresh
  • by relevance
  • by date
  • by rating

Как я навел порядок страниц в Фигме

Web design *Interfaces *Mobile applications design *Design

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

Читать далее
Total votes 7: ↑6 and ↓1 +5
Views 4.7K
Comments 11

Код ревью, как внедрить и не испытывать боль

JavaScript *IT Terminology TypeScript *
Sandbox

Если вы работаете в продуктовой компании, то жизненный цикл почти каждого продукта будет соответствовать принципу Парето:
- 20% времени мы пишем новый код.
- 80% времени поддерживаем старый. Поддержка в себя включает фиксы багов, обновление кодовой базы (переезд на новые библиотеки например).

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

Читать статью
Total votes 20: ↑19 and ↓1 +18
Views 7K
Comments 29

Учиться на ошибках: 3 кейса, которые научили нас грамотно проектировать VUI

Interfaces *Usability *Artificial Intelligence Voice user interfaces

Привет! Меня зовут Юля Мицкевич, я операционный директор команды дизайна и разработки разговорных продуктов TORTU компании KODE. 

Наша команда уже более 3 лет занимается проектированием и разработкой VUI: от чат-ботов и телефонных систем до виртуальных ассистентов. Мы помогаем бизнесу обрести свой голос. Активно участвуем в проектировании навыков для Сбера, Тинькофф, HeadHunter, Mail.ru Group, Delivery Club и других крупных компаний. Также развиваем профессиональное сообщество: ведём Telegram-канал 'Hey Voice!'

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

Читать далее
Total votes 3: ↑3 and ↓0 +3
Views 931
Comments 0

Умный аналитик – глупый разработчик vs. глупый аналитик – умный разработчик

System Analysis and Design *Development Management *

Или как понять, когда остановиться

Как-то раз мой коллега, лид разработки, после затяжного спора о том, что должно быть в системной спецификации, подошел ко мне и спросил:

— Скажи, а зачем нам вообще нужны аналитики?

— И действительно, зачем? – подумал тогда я и написал заявление

Вопрос этот, как бы крамольно он ни звучал, очень правильный. Системный анализ, как фаза разработки приложения, присутствует всегда (даже если это системы класса «Hello, world»), а вот системный аналитик, как выделенная роль – нет. Выделение отдельной специальной роли работает точно так же, как и разделение труда в обычном производстве: для маленьких задач не целесообразно, для больших задач – оправданно. При таком разделении  системный аналитик забирает на себя часть задач и функций некоего «универсального» исполнителя задачи. Однако, подобное разделение труда имеет свою цену: это потеря знаний при коммуникации, более сложное управление процессом и др. В этой статье я хочу поделиться своим опытом: описать минусы крайностей и дать рекомендации по распределению обязанностей между системными аналитиками и разработчиками.

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

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

Заключается эта проблема в том, что между сбором и систематизацией требований (прямая и понятная задача аналитика) и непосредственно кодированием (прямая и понятная задача разработчика) есть область проектирования решения; задачи из этой области могут и должны выполнять обе роли.

Читать далее
Total votes 22: ↑21 and ↓1 +20
Views 9K
Comments 24