Рубрика «проектирование» - 24

Пока я писал о проектировщиках и прототипах, внезапно выяснилось, что многие читатели не представляют, о чём идёт речь. Поэтому сегодня я решил рассказать о том, что такое интерактивный прототип, сделанный в Axure (произносится как «Экшер», а я привык говорить «Акшура»). И не только рассказать, но и показать.

Если совсем грубо, то интерактивный прототип — это набор связанных друг с другом html-макетов. Только работали над этими макетами не дизайнер с верстальщиком, а проектировщик в специализированной программе, позволяющей сделать эту работу в разы быстрее. В чём будет различие в результате? Прототип, подготовленный проектировщиком, в отличие от макетов, подготовленных верстальщиком, не предназначен для разработки. Он призван очень быстро и наглядно продемонстрировать то, что исполнитель будет воплощать в жизнь на следующих этапах. Это всё равно, что трёхмерная модель готовящегося к строительству здания. На её создание уйдёт гораздо меньше времени, чем на постройку, и она позволит виртуально побродить по будущему проекту.Читать полностью »

Недавно я написал:

Для программных продуктов еще не придумали адекватные инструменты визуализации. Об этом говорил еще Брукс, почти 40 лет назад. Поэтому разработчики ПО часто уподобляются слепым монахам из буддийской притчи.

Следствие #5. Необходимость постоянных коммуникаций участников разработки.

Из опыта. В среднем у каждого участника проекта разработки ПО на всякие разговоры уходит 50% рабочего времени. У нас это называется «синхронизация ментальных моделей».

И вот, как это обычно выглядит.


Читать полностью »

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

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

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

Метрика #26 — Подкаст о технологиях, продуктах и сервисах из мира ИТВсем привет! С вами «Метрика» — шоу для тех, кто создает и анализирует продукты и сервисы, проектирует и руководит, занимается бизнесом и любит новые технологии.

Сегодня в программе

В 26 выпуске Метрики вы сможете послушать интервью Платона и нашего специального гостя Александра Кирова, дизайнера продуктов в Pebble.
Читать полностью »

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

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

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

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

Я имел дело с перекупщиками, которые понятия не имели, чего хочет конечный покупатель, я встречал неадекватов, которые понимали как надо только после того, как мы сделаем, как просят.

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

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

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

Так вот — каждый раз, когда я встречал очередного «чего там работать, сделайте как в фейсбуке» клиента, я давал себе слово, даже нет – я клялся могилами предков, что вот уж я бы на его месте так себя не вел. Я бы на его месте работал так, что разработчик еще и приплачивал бы за удовольствие иметь со мной дело. Уж я бы на его месте мог бы стать просто самым лучшим заказчиком. И однажды я им стал.

Читать полностью »

О том, как мы делали игру «Стикеры» для Google Play
О том, как мы делали игру для Google Play

Давно у меня была мысль поделиться своими знаниями с сообществом. Сначала хотел написать что-нибудь по астрофизике или ОТО, но решил все же что корректнее будет писать о той предметной области, которой я занимаюсь профессионально. Итак, я постараюсь подробно изложить процесс создания и тонкости реализации игрового приложения под Android (начиная от проектирования, заканчивая публикацией и In App покупками).
Читать полностью »

Код с одной и той же структурой в двух и более местах — верный признак необходимости рефакторинга. Если вам нужно будет что-нибудь изменить в одном месте, то, скорее всего, нужно также сделать то же самое и в других местах. Но есть близкая к 100% вероятность не найти эти места или попросту забыть за них.

Большинство понимает, что многократное повторение кода (или copy-paste) в примере ниже — зло:
Читать полностью »

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

В новой статье мы хотим развеять очень устойчивое и популярное заблуждение: «результат проектирования — документ или прототип». Такая мысль, по умолчанию прошитая в головах всех клиентов и почти всех исполнителей, выливается в серьёзные финансовые потери.

Читать полностью »

В этой статье я представлю свое видение того, на каком этапе развития находится САПР для проектировании крупных промышленных предприятий сегодня, с какими трудностями приходится сталкиваться при внедрении и какие тенденции намечаются в этой отрасли.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js