20 заметок с тегом

как работаем

Само собой разумеется

В техническом задании всего не опишешь. Есть общепринятые моменты, которые могут быть не описаны в ТЗ, но их реализация подразумевается.

Моменты зафиксированные в настоящей статье реализуются в режиме «само собой» в любом из наших проектов.

• 1. Авторизация нажатием по кнопке Enter (на клавиатуре компьютера), не только кликом мышью по кнопке входа.

• 2. Выпадающий список не только выпадает, но и прокручивается.

• 3. Радио-кнопка выделяется не только нажатием на пимпочку, но и кликом по слову.

• 4. Маска телефонного номера в полях ввода телефонного номера.

• 5. Видимая реакция (отклик) при нажатии на кнопку.

• 6. Дату и время (когда видим рядом) отделяют друг от друга два пробела: 03.08.2022 16:06

• 7. Модальное окно исчезает при клике по экрану за пределами модального окна.

• 8. Количество цифр, которое можно ввести в поле ИНН — 12.

• 9. Обязательное для заполнения поле не помечаем звездочкой. Если обязательное поле не заполнено, при нажатии на кнопку отправки формы — подсвечиваем рамку поля красным (при этом отправка формы блокируется).

2022   блог   как работаем

Культура делового общения

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

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

2022   блог   как работаем

Эволюция бизнеса: помогаем расти и меняться

Жизнеспособный бизнес пробивается «сквозь асфальт», без оглядки на внешнюю привлекательность. В первое время это оправдано, но наступает момент когда владельцу бизнеса все чаще становится неловко за своего работоспособного «Франкенштейна».

Помогаем улучшить:

1. Наружную оболочку компании:
— Дизайн сайта;
— Дизайн промо-материалов;
— Дизайн интерфейсов;
— Тексты и редактура;
— Коммуникация через соц. сети.
 2. Нутро компании:
— Внутренние повторяемые процессы;
— Интерфейсы сотрудников;
— Визуализация и анализ данных;
— Логистические процессы;
— Маркетинговые процессы.

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

2021   блог   как работаем

Creative UX

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

Мы занимаемся как раз этим — креативим пользовательский опыт.

2021   блог   как работаем

Осознанное незнание

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

Описанный метод мы используем при формировании технического задания — в ТЗ описывается, что мы хотим получить в результате, но нет ни слова о том как это будет реализовано (мы осознанно не хотим этого знать).

2021   блог   как работаем

Без акта выполненных работ

Да, мы работаем без актов выполненных работ.

Какую функцию выполняет акт выполненных работ
Актом выполненных работ принято закрывать действие договора.

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

И как тогда закрывать действие договора?
Например, так:
Если Заказчик не обратился в Дизайн-бюро с претензиями в течении десяти дней после перечисления второй части оплаты — действие данного договора заканчивается.

Что делать, если бухгалтерия привыкла работать с актами?
Если без акта никак — рекомендуем составить акт об отсутствии акта (в связи с иными условиями прекращения действия договора).

2021   блог   как работаем

Что под капотом?

Используем безотказные веб-технологии, успевшие стать классикой:

Акроним LAMP может использоваться для обозначения:
— Инфраструктуры веб-сервера;
— Парадигмы программирования;
— Пакета программ.
Хотя изначально эти программные продукты не разрабатывались специально для работы друг с другом, такая связка стала весьма популярной из-за своей гибкости, производительности и низкой стоимости (все её составляющие являются открытыми и могут быть бесплатно загружены из Интернета).
Википедия

2021   блог   как работаем

Техническое задание на разработку ПО




Примеры технических заданий:

ТЗ на разработку онлайн сервиса бронирования чартерных рейсов
ТЗ на разработку системы учета клиентов (лидов) торговой компании
ТЗ на разработку системы управления торговой компании (управление складским комплексом)
ТЗ на разработку системы управления транспортной компании
ТЗ на разработку системы управления программой гармонизации нейро-активности



Портфолио разработанного ПО: CRM, ERP, системы управления
18 проектов | Разрабатываем CRM на заказ


Важность технического задания при разработке ПО
ТЗ является ключевым документом при разработке программного обеспечения. Его основная цель — четко и подробно описать требования и ожидания заказчика, а также определить функционал, архитектуру и технологии, которые будут использоваться в процессе разработки.

Что дает техническое задание:

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

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

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

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

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

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

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

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

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

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

    Структура технического задания
    Наше ТЗ состоит из следующих элементов:
  • Макеты интерфейса. Мы используем скриншоты интерфейса страниц и модальных окон разрабатываемого ПО. Это наглядные изображения, которые помогают лучше представить внешний вид и компоненты каждой страницы.
  • Описание функционала. Каждая страница макета сопровождается подробным описанием функционала. Мы описываем, какие операции и взаимодействия доступны на каждой странице, какие данные можно вводить и выводить, а также какие действия могут выполнять пользователи.
  • Связь между разделами. Важной частью нашего ТЗ является установление связей между разделами и элементами управления. Мы используем ссылки для показа связей между разными разделами, страницами и элементами интерфейса. Это помогает разработчикам легко перемещаться по ТЗ и быстро найти связанные элементы.

    Оформление ТЗ
    При оформлении технического задания следуем определенным принципам и стандартам, чтобы обеспечить понятность, структурированность и информативность документа. Основные аспекты, которые используются при оформлении ТЗ:
  • Титульный лист: На титульном листе указываем название проекта или продукта и сведения об авторстве.
  • Включаем содержание, где перечислены все разделы и подразделы ТЗ. Содержание позволяет быстро найти нужную информацию и легко переходить между разделами по ссылкам.
  • Структура и нумерация. Структурируем ТЗ на основе составных частей или разделов разрабатываемого ПО. В каждом разделе указываем подразделы и описываем требования и функциональность в последовательности, которая обеспечивает логическую связь и понимание проекта. Каждый раздел и подраздел нумеруется, чтобы облегчить ориентацию в документе.
  • Описание функциональности. Подробно описываем функциональность ПО, включая его возможности, основные задачи, интерфейсы, взаимодействие с пользователями и системами, а также ожидаемые результаты. Используем понятный и ясный язык, избегая сложных терминов и специфического жаргона.
  • Интерфейс и макеты. Включаем скриншоты интерфейса и ссылку на набор макетов всех страниц и модулей ПО. Это помогает визуализировать ожидаемый внешний вид и структуру приложения, облегчает понимание требований к пользовательскому интерфейсу и взаимодействию.
  • Используем таблицы, когда это актуально. Таблицы обеспечивают более ясное и структурированное представление информации.

    Пример использования таблицы в техническом задании

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

    Пример использования схемы работы в техническом задании

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

    Что дает внутренняя перелинковка
    Внутренняя перелинковка в техническом задании обеспечивает ряд значительных преимуществ, которые упрощают процесс разработки и улучшают качество конечного продукта:
  • Улучшение навигации. Ссылки между различными частями ТЗ позволяют команде разработчиков быстро и легко переходить от одного раздела к другому, если они взаимосвязаны. Это сокращает время, затрачиваемое на поиск необходимой информации, и упрощает процесс работы с ТЗ.
  • Повышение понимания. Перелинковка помогает лучше понять взаимосвязь между различными элементами программного обеспечения, что способствует более глубокому пониманию проекта в целом.
  • Уменьшение ошибок. Когда разные части ТЗ тесно связаны друг с другом, меньше шансов допустить ошибку или недопонимание. Если изменения в одном разделе затрагивают другой раздел — перелинковка облегчает отслеживание этих связей и предотвращает возможные проблемы.
  • Улучшение коммуникации. Внутренняя перелинковка улучшает коммуникацию внутри команды разработчиков, так как она обеспечивает удобный способ ссылаться на конкретные части ТЗ в обсуждениях и переписке.
  • Повышение эффективности. Хорошо структурированное ТЗ с активной внутренней перелинковкой значительно повышает эффективность рабочего процесса команды разработчиков, уменьшая время на поиск и анализ информации и упрощая процесс принятия решений.


    Внутренняя перелинковка в техническом задании.

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

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

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

    Уровень образования для чтения ТЗ
    Уровень образования не является определяющим фактором для чтения технического задания. Главным критерием является нормальный уровень владения русским языком и желание вникнуть в суть ТЗ.

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

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

    Благодаря детальности и структурированности ТЗ, команда разработчиков может провести точную оценку стоимости ПО. ТЗ дает возможность разбить проект на отдельные задачи, определить зависимости и риски, а также учесть дополнительные факторы, которые могут влиять на стоимость разработки.
    • 2018   блог   как работаем

    Оферта — рабочий рычаг

    Оферта — это публичный договор. Т. е. публично предлагается любому, кто примет оферту оказать услугу (или продать товар) на описанных в оферте условиях. Условия принятия оферты могут быть разными, но действие должно быть четким, желательно с фиксацией времени. Таким действием часто назначают факт оплаты услуги банковской картой.

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

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

    2018   блог   как работаем

    Метод гребли по течению. Когда точно не знаем, куда плыть.

    Когда понятно чего хочется, но не ясно «как?» — целесообразно использовать метод гребли по течению. Его суть проста — намечаем цель и плывем к ней по течению. Но не как гавно, а помогаем — гребем веслами.

    Намечаем цель, собираем информацию, отмечаем чекпоинты, триггеры уведомлений. Проектируем интерфейсы и архитектуру баз данных, расписываем ТЗ, готовим макеты. Редко бывает так, что сразу понятно, каким будет проект. Главное, донести мысль — какие цели преследуются. Далее — весла опыта и знаний вынесут нас в точку достижения пользы.

    2018   блог   как работаем

    Сбор информации

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

    Чтобы сделать сайт парикмахерской, нефтяной компании или о талантливом поэте — необходим главный строительный материал, информация. Собирать информацию можно в программе Трелло, она бесплатна.

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

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

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

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

    2018   блог   как работаем
    2017   блог   как работаем   клик   такнадо

    Человечный интерфейс

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

    Идиотека от 13 агуста 2007 года, фото — Алексей Шкляр

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

    2017   блог   как работаем

    Польза — движущая сила

    Если проанализировать историю человечества, главной движущей силой была и остается польза. Моисей организовал исход из Древнего Египта; Колумб поплыл пошел в Индию и случайно открыл Америку; Джобс разработал Макинтош — всё ради пользы.

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

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

    Польза и проект — не одно и тоже. Часто, чтобы реализовать проект нужно выполнить несколько итераций. Результат выполнения каждой итерации — пусть небольшая, но польза. Только так, иначе пропадает всякий смысл.

    2017   блог   итерация   как работаем   польза   понимание задачи   принцип   сколько стоит   стоимость

    Флексить: зачем и как?

    Flex по-английски — гнуть. Иногда бывает так, что лучше «подогнуть» проект, но сдать в срок и в рамках бюджета, чем продолжать жить без реализованного проекта. Если польза от запущенного проекта важнее некоторых неудобств, лучше флексить.

    Николай Товеровский из Бюро Горбунова проделал большую работу — выделил и описал приёмы флекса (за что ему большое спасибо). Представляю «выжимку» из его работы со ссылками на статьи.


    Виды флекса:

    1. Зафиксировать

    Часть системы делается статичной, её невозможно изменять или настраивать, поведение определяется заранее запрограммированным алгоритмом.
    Подробнее

    2. Снизить управляемость

    Систему делают менее управляемой, но не жертвуют качеством и работоспособностью.
    Подробнее

    3. Уменьшить глубину проработки

    Работа ведётся только над тем, что необходимо для решения задачи.
    Подробнее

    4. Рассогласовать

    Изменяют только необходимую часть системы, игнорируя рассогласование с другими частями.
    Подробнее

    5. Убрать в гаражик

    Неблаговидная часть системы прячется так, чтобы не портила вид.
    Подробнее

    6. Заменить решение

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

    7. Не выходить в надсистему

    Решение не затрагивает других частей системы.
    Подробнее

    8. Отступить от идеала

    Если реализовать идеальное решение невозможно или нерационально, отступите на шаг назад.
    Подробнее

    9. Перенести на следующую итерацию

    Часть функций откладывают на потом.
    Подробнее

    Сделать говно

    Сделать говно — это не пофлексить.
    Подробнее

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

    Лучше синица в руках, чем журавль в небе. Мы помним, что такой инструмент как флекс существует и умеем им пользоваться.

    2017   блог   инструмент   итерация   как работаем   ссылка   флекс   ффф

    Работаем близко

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

    Мы делаем сайты, мобильные приложения и системы управления предприятиями. Реальной оффлайновой встречи может потребовать лишь разработка системы управления, т. к. для разработчика важно видеть как устроено предприятие в реальности. Что касается сайтов — оффлайновая встреча, это лишняя трата времени.

    Все знают, что такое скайп. Но не все знают, что в скайпе можно включать режим демонстрации экрана — незаменимый инструмент при обсуждении деталей проекта. Бывает, что нужно «прикрутить» сайт к 1С — на помощь приходит другой инструмент, Тимвивер (позволяет подключиться и полностью управлять удаленным компьютером).

    Имея упомянутые инструменты — тратить пол дня, чтобы обсудить работу глупо, дорого и неэффективно. Клиенты разделяют наши взгляды и быстро начинают ценить возможность из любого места, в удобное время эффективно поработать над проектом. При очной встрече не удобно вдвоем (или втроем) пялиться в один экран, во время разговора по скайпу в режиме демонстрации экрана — все внимание приковано к предмету обсуждения. Такая работа, по крайней мере в области разработки сайтов, более эффективна. А кто придумал назвать такой способ коммуникации «удаленным» — ума не приложу.

    2017   блог   как работаем   принцип   удаленная работа

    Текст — всему голова

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

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

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

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

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

    Если коротко, тексты в информационном стиле не навязывают мнение и настроение. У них нет цели загипнотизировать пользователя или манипулировать им. Информационный стиль не ставит своей целью заискивать с посетителем, или развлечь его. Инфостиль объективно, точно и лаконично доносит информацию «как есть». Автор неформально и однозначно информирует пользователя и помогает принять взвешенное решение. Причем, взвешенное решение может быть «не покупать». Принимать решение — дело посетителя, решение зарождается внутри его головы, а не навязывается вычурным текстом.

    Это сжатое представление об информационном стиле. Если бы я мог описать его принципы на одной странице — Максиму Ильяхову не пришлось бы много лет собирать материал и писать книгу. Если хотите углубиться в тему — изучите справочник Главреда или прочитайте упомянутую книгу.

    Взглянем на примеры. Как инфостиль преображает текст.

    До применения инфостиля
    Отдельного внимания заслуживает продукция марки Рифар, а именно монолитные алюминиевые и биметаллические радиаторы, обладающие прекрасными характеристиками и впечатляющей мощностью. Они идеально подходят для условий российского климата, а также могут в короткие сроки обеспечить обогрев довольно просторных помещений.
    Сайт компании «Дельта»     		В инфостиле
    Монолитные алюминиевые и биметаллические радиаторы «Рифар» подходят для условий российского климата и могут в короткий срок прогреть просторное помещение.
    До применения инфостиля
    Упаковочные материалы от компании «Алита» — это современная и качественная продукция. Ее выбирают десятки предприятий в Москве и Московской области. Мы предлагаем все, что нужно, чтобы быстро, надежно и удобно упаковать или оформить любой товар и материал. Наша упаковка используется на производствах и складах, в магазинах и дома — она нужна везде.
    Сайт компании «Алита»     		В инфостиле
    «Алита» обеспечивает десятки предприятий упаковочными материалами. Они применяются на складе и производстве, в магазине и дома — везде, где оформляют и упаковывают предметы.
    До применения инфостиля
    Мы приветствуем Вас на сайте компании ООО «МирЛопат». На нем есть полная информация по продукции нашего производства.
    Мы производим снегоуборочный инвентарь и другие товары с 2006 года. Используя передовые технологии, мы можем предложить в отрасли лучшие цены, отличное качество изделий, быстрый ответ на любые предложения наших клиентов.
    Мы будем рады увидеть вашу компанию среди наших постоянных клиентов.
    Сайт компании «МирЛопат»     		В инфостиле
    ООО «МирЛопат» делает инвентарь для уборки снега с 2006 года.


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


    Примеры статей в информационном стиле:
    Хорошо ли продавцы в электричках хвалят свой товар Людмила Сарычева
    Как устроен банкомат Сергей Король
    Почему дисциплина лучше мотивации Андрей Банников

    Текст в инфостиле на сайтах:
    Энциклопедия услуг «Почты России»
    Сайт дилера сотовых операторов
    Агентство спортивного маркетинга

    Ссылка по теме: Лекция Максима Ильяхова об информационном стиле

    2017   блог   видео   информационный стиль   инфостиль   как работаем   ссылка   статья   текст

    Управление разработкой

    Картинки без программирования, как усилие воли без действия — ничто. Но, как без усилия воли не будет действия, так и без визуального представления проект не запрограммировать.

    Программируем каталог товаров. «А какая структура каталога?» — спросит программист. Что ему ответить, если нет макета, если не представляем как будет выглядеть сайт? Вся логика продумывается на этапе проектирования дизайна, но не всё просматривается глядя на макеты. Что будет, если вместо квадратных иллюстраций (как нарисовано в макете) загрузить горизонтальные? «Как их выравнивать?„ — последует следующий вопрос программиста. Нельзя забывать о том, что дизайн не статичен. Реакция интерфейса на действия пользователя — это тоже дизайн.

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


    Дизайнер → Клиент ↔ Программисты

    Клиент остается с картинками, сам находит программистов. Ставит задачу, контролирует ход исполнения, тестирует результат. → На результат без слёз не взглянешь ;(

    Дизайнер ↔ Клиент ↔ Программисты

    «Авторский контроль» — дизайнер атакует замечаниями клиента. Клиент передает их программистам. Программисты ставят замечания в очередь, но новые поступают быстрее, чем реализуются предыдущие. → Запускается сырой продукт, не похожий картинку.

    Клиент ↔ Дизайнер ↔ Программисты

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


    Продолжу аналогию, приведенную в начале поста. Если дизайнер это усилие воли, программист — действие, то клиент это мозг. Из мозга поступает сигнал, возникает усилие воли (намерение), в результате чего производится действие.


    Мозг → Намерение → Действие



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


    Иллюстрация макета веб-страницы: совет Артёма Горбунова о модульной сетке

    2017   блог   как работаем   клиент   программист   разработка   ссылка   управление

    Итерационный подход

    Проект нельзя реализовать только лишь усилием воли. Реализация зависит от конкретных действий живых людей. Если действие мотивировано — его не придется долго ждать. Благодаря итерационному подходу интерес к проекту не затухает у исполнителей. А заказчик точно знает за что платит и на каждом этапе получает ощутимую пользу.

    Каждая итерация, по сути, представляет из себя небольшой проект и имеет четкий срок сдачи (дедлайн). Может состоять из набора разных работ, успешное выполнение которых приведет к реализации оговоренных функций. У каждой итерации может быть своя цель, но обязательный атрибут каждой итерации — это польза.

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

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

    2017   блог   итерация   как работаем   польза   проект   результат   управление

    Понимание задачи

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

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

    Пример реальной заявки на разработку сайта:

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

    Формулируйте задачу на языке бизнеса, не нужно её формулировать на языке дизайнера. Ведь сайт, система управления, мобильное приложение — это инструменты для решения задач в бизнесе. Но это не единственные инструменты и не всегда все работает так, как задумано. Чтобы привлечь внимание на выставке — девушка модельной внешности в костюме красной шапочки может сработать эффективнее, чем отличная статья и детально продуманная инфографика.


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

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

    Нет Да
    Сделать красивый и современный дизайн сайта Повысить доверие пользователей к сайту



    По итогам первых переговоров клиент получает документ «понимание задачи», который представляет из себя обычное электронное письмо. Документ не влечет никаких обязательств, но со старта дисциплинирует работу над проектом и позволяет клиенту убедиться в том, что дизайнер понял задачу. Одно дело кивать головой и поддакивать, совсем другое — письменно описать понятное. В тексте описывается не только задача на языке бизнеса, но и способ решить её (на языке дизайнера). Мы приходим у формуле:

    Сделать то-то, сделав это



    Вышесказанное можно проиллюстрировать проще. Мы приходим в парикмахерскую и объясняем причину, побудившую нас обратиться к парикмахеру (в чем дискомфорт сегодняшней прически, для каких целей нужна другая). Мастер входит в положение и советует как постричься. Если предложение устраивает — стрижемся.



    Конечно, можно прийти к парикмахеру и обозначить параметры стрижки — длину локонов на каждом участке головы, угол скоса челки, интенсивность прореживания. Но опытный парикмахер не возьмется за такую задачу. Ведь если прическа не понравится виноват, все равно, будет парикмахер (хотя сделал как просили). Опытный парикмахер ценит клиента и своё душевное спокойствие. Смотрит глубже, устраняет дискомфорт и приближает к цели. Поэтому хорошие парикмахеры ценятся и к ним всегда возвращаются. Даже несмотря на то, что у них дороже.



    Ссылка по теме: Лекция Ильи Бирмана о понимании задачи

    2016   блог   видео   задача   как работаем   понимание задачи   ссылка
    © Алексей Шкляр, 2016—2024 РСС
    Движок — Эгея