Кликнул на слово "обосраться", а в статье ни одного крепкого словца. Ожидания обмануты, осадочек остался. :D
На самом деле, классная статья, спасибо 💙
Большое спасибо за развёрнутые комментарий и поддержку!💙
На вкус и цвет каждому свой сайт, как говорится) Контент на vc всегда собирает противоречивые мнения.
Сразу видно мнение профессионала. А говорят на vc не бывает объективной критики.
Напишите, что конкретно не так, и пару референсов сайтов, которые не "дерьмовые", а "как надо"? Мы новому дизайнеру скинем, как пример.
Как сейчас помню, факап-факапыч :) Нормально же на Тильде работало, чего выдумывать начали? :D
Себе почему-то всегда тяжелее сделать нормально. Внутренние проекты идут слабым приоритетом, при этом хочется сделать ого-го! В итоге идёшь бегать по грабельному полю :) - классика.
Мысль пришла: то что мы классные исполнители не всегда будет значить, что мы ещё и классные заказчики.
Отличная работа! Для первого раза - вообще огонь) Ждём вторую статью по итогам. Интересно сколько наймёте.
Немного вдохновения для вас из нашего опыта:
У нас стажировки заиграли новыми красками после того как мы более активно начали работать с местным университетом. Сейчас читаем там несколько брендированных курсов. С этих курсов приходят очень классные ребята на стажировки. Думаю для вас это тоже был бы хороший следующий шаг.
Очень помогает настроить ребят на нужный лад, дать более актуальную инфу, чем та что зашита в базовой университетской программе.
У нас часто просто не хватает мест для всех крутых проспектов оттуда. В весеннюю стажировку набрали 5 человек )) довольно быстро растут до крепких джунов.
У нас слегка отличается технология стажировки. Мы делаем учебный проект и набираем несколько команд. В каждой команде: разработчики, тестировщик, дизайнер и ПМ. Команды пилят один и тот же проект под руководством наших ребят. Стараемся создать что-то типа реальной коммерческой атмосферы работы. В конце демо проекта. Отлично даёт понять сильные и слабые стороны всех включая софты.
Возможно тоже нужно статью запилить 🤔🤔🤔
Для наглядности исходный логотип и новый:
Вот это я называю вдумчивым комментарием!
Спасибо, Марат! Тянет на отдельный пост 🔥🔥🔥
Про борьбу синего и красного. Наверное в этом что-то есть. Уже не помню свои первые впечатления. Но теперь буду обращать внимание на такие моменты)
Но по прошествии времени, могу точно сказать: Логотип получился легковесный, достаточно привлекающий внимание, им легко манипулировать и использовать, классно ложится на картинки, презентации и т.д.
Отличная статья, спасибо! Яндекс улетел в стратосферу, и это заставляет их местами стагнировать.
Стоило разбить на отдельные статьи наверное, а то как будто сериал за раз посмотрел :)
Интересный кейс, спасибо, что поделились)
Думаю тема коммуникаций с заказчиком достойна отдельной статьи :)
Когда писал ответ на коммент, а получилась ещё одна статья 🤪
Есть правильные мысли у вас. Но мы немного про разное говорим. Давайте ещё раскрою контекст:
Есть проект на создание ИС для автоматизации бизнес-процесса.
Есть заказчик, который выкатывает ТЗ, как чувствует и как видит.
Обычно в этом тз нет достаточной информации, чтобы приступить к работе.
Следующий этап доуточнить ТЗ. Здесь можно использовать разные инструменты в т.ч. и нотации. На этом этапе аналитик или проектировщик идёт "в поля". На этом этапе нужно собрать обратную связь от пользователей (они обычно не шарят в этих наших нотациях) и внимательно читать ничего не будут (либо не заметят важных деталей).
Условно: есть менеджер какой-то фирмы, он будет пользователем системы, которую мы разрабатываем. Он мало заинтересован в проекте, у него есть своя работа и обычно ему ок и так работается. С такого тяжело собирать обратную связь.
Для решения этой задачи проектировщик превращает существующую задачу в более понятный вид (это и есть то, что мы называем граф ТЗ) это такой артефакт который мы в первую очередь показываем пользователям и заказчику, и по которому собираем информацию. А то что нам нужно узнать в процессе, выносим сюда же в вопросы.
Выглядит это так условно: вот экран, на нём вы будете делать то же самое, что вы вот в этой своей допустим эксель табличке делаете (или ещё как-то). Сюда вводите данные, вот такая формула применяется, и т.д.
Полученная информация ложится на те скетчи, что есть на картинке.
В финале вопросов не остаётся и получается артефакт из которого далее мы будем делать дизайн.
То есть граф ТЗ — это не про то, что мы "блок-схемы изобрели", это про подход доуточнения требований. Можно придумать разные названия, если вам так не нравится ТЗ вплетать сюда))
Статья об этом и есть: как базовые нотации подать клиенту так, чтобы ему было проще их читать.
Смысл в том, что на стороне заказчика есть люди, которые шарят, а есть те, кто не шарят, но они будут будущими пользователями. Их не нужно учить читать нотации, им нужно показать так, чтобы было удобно.
4. По стилю и подаче — на вкус и цвет.
3. "Ну и тут уже выше сказали, вы изобрели монструозный велосипед. Есть исчерпывающие наборы нотаций, красиво и грамотно решающие ваши вопросы."
Есть различные нотации, это да. Нотации — это хорошо. Но нотация, это не цель, а инструмент. Его можно менять и настраивать под задачу. Можно всё идеально сделать по стандартам и с использованием самых красивых нотаций и при этом провалить проект.
Здесь мы всего-лишь показываем, какая комбинация методик работает у нас. Не претендуем на то, чтобы называть это стандартом или насаждать кому-то.
Инструменты под задачу, а не задачи под инструменты. Главное, чтобы проект успешный был.
Если вы знаете набор инструментов, который может оптимальнее работать, то расскажите. Интересно послушать.
2. "Наверное, вы не понимаете, что такое ТЗ. На чёрной картинке у вас не ТЗ, а изучение предметной области, выявление требований.
Я задам встречный вопрос: а что является одним из продуктов "изучения предметной области и выявления требований", если конечная цель это создание ИТ систем?
Вот вам определение ТЗ:
"Техническое задание - это инструмент коммуникации между заказчиком и исполнителем, который помогает выстроить линию общения с помощью создания внутри него некоего абстрактного элемента, наделенного видением, чувствами и знаниями заказчика."
Как это идёт в разрез с тем, о чём говорится в статье?
Спасибо за комментарии по существу.
1. Тут комментировать не буду. В целом по-разному можно интерпретировать. Как не назови, главное, чтобы помогало в решении реальных задач.
Ну тут согласен))
Но блок-схемы блок-схемам — рознь.
В общем-то хоть даже наскальные рисунки, главное, чтобы работало и положительно сказывалось на качестве продукта.
Нам “блок-схемы” помогли на более ранних этапах разработки поднимать важные для проекта детали, и лучше погружать в логику продукта разных участников процесса от технических исполнителей до юзера, который может быть даже не “уверенный пользователь ПК”.
1. По длительности. Где-то х1,5 к обычному текстовому описанию с таблицами.
Но в больших системах, чаще всё помодульно делается. То есть решение дробится на куски, и затем уже на каждый кусок отдельно будет готовиться граф-ТЗ.
Не всегда так, к сожалению. Последнее время заметил, что многие компании переизобретают подход к требованиям, и логично, что постепенно все идут в одном направлении. Но на практике пока редко такое вижу.
Всё ещё часто бывает, что аналитик что-то писал там 2-3 месяца, а потом это где-то в confluence лежит никем никогда не открытое, потому что на этапе дизайна какие-то совершенно новые вводные идут :)
2. Ой жиза. Классическая проблема, когда UX прототип начинают обсуждать как итоговый UI и просят поправить скругление на кнопке. :D Важно вовремя и грамотно объяснять заказчику какой уровень детализации обсуждаем и зачем, тогда проблем не должно быть.
Это фреймы в Figma или можно в FigJam, в зависимости от того, кто делает и какой уровень детализации нужен. (кому как удобнее)
Вообще, всё целесообразно в одном месте держать: в одном Figma-файле на разных страницах будут ТЗ, UX прототип и финальный дизайн.
На таком масштабе уже тяжело бизнес-процесс переделывать, поэтому выбирают уже между злом таблицы и злом перестройки бизнес-процессов и инструментов.
В общем, у нас и не было какой-то острой проблемы с процессом. Но скорее всего зависит от масштабов проектов.
У нас проекты в основном длительные (от шести месяцев), то есть такой проблемы нет, что куча проектов и непонятно кто где занят и когда освободится. Получается проще оркестрировать.
Но в целом всё верно. Чем раньше начнёшь выстраивать процесс, тем проще будет даваться.
Пользуемся вашей тулзой для ретро) шлю лучи добра и уважения вам. Классная и минималистичная штука, удобнее, чем в конфле.
Спасибо, что поделились! А сколько человек производственников в компании?
(интересно с какого количества человек вы начали выстраивать этот процесс)
По статье есть ощущение, что звучит сложновато... Оверхэд, так сказать :)
Но возможно это из-за большого коллектива.
Ещё интересно, как давно вообще появилась позиция операционного менеджера? На каком объёме сотрудников появилась необходимость выстраивания процессов?
Мы в прошлом году начали искать решение проблемы для синхронизации загрузки, и в итоге накастомили свою мини-ERP с отображением загрузки, сейчас добавили ещё и финансовые показатели для отслеживания маржинальности проектов и сотрудников.
Знатная охота у вас вышла. Красавчики! Сайты кайфовые у вас, топ за свои деньги 👏
Мы с QSOFT и KOTELOV рубились за топ корп. порталов. Мне кажется, там все три места были отличные.
2) Это вы про вот этот комент?
"... Нас очень странно за накрутки ругать, учитывая среднее количество лайков и коментов на наших постах."
Это по вашему мнению подтверждение какое-то?
Я там пишу о том, что часто сотрудники лайкают статьи своей компании - это окей. Но мы, может даже к сожалению, таким не злоупотребляем. Доказательство: другие наши статьи, где такой движухи и близко нет.
Понимаю вашу боль, когда какие-то пустые статьи получают незаслуженный охват. У меня тоже бывает подгорает с этого. Естественно придёт кто-то и будет хэйтить, и такой комент наберёт много лайков :)
Но вроде бы этого нельзя сказать про этот пост.
По многим ударил кризис. Это полезный опыт. Мы шарим его в интернете, чтобы те, кому повезло больше в прошлом году, могли посмотреть и что-то извлечь на будущие вызовы. Конкретные цифры пошарили и меры. Редко кто так открыто говорит про проблемы и деньги.
Если вам это неинтересно, то можно пройти мимо.
По поводу обсуждать между собой.
Не я автор этой статьи. Но я был в компании в прошлом году, и мне есть что сказать со своей точки зрения сюда. Я пишу комент с позиции человека, который эту ситуацию видел с другой стороны. Чем этот комент плох?
У других ребят есть ещё мнение: нужно дать компенсации на питомцев. Окей - тоже мнение, почему бы и не высказать? Идея найс, почему не обсудить, может кто-то из других компаний подхватит.
Если вам не интересно это обсуждение, можно пройти мимо.
Вообще, этот кот рисовался как Леонид Котевский, но это уже совсем другая история...
Если кто-то не лайкнул и не оставил комент, то выговор, ставил в угол на горох и бьём розгами. (нет)
Был на конфе. Спасибо за организацию и за статью, супер-полезно сейчас почитать как всё задумывалось и какие выводы сделали.
Закину каплю обратной связи:
Плюсую Артёму, кино-постеры - топ идея. Жаль, что не реализовали( Как будто даже странно выбирать обычные постеры, когда была возможность выделиться и запомниться чем-то уместным.
Конфа в кинотеатре - это прям понравилось. В будущем можно ещё докрутить: сделать все выступления без света, раздавать\разыгрывать попкорн, мб даже рекламу самой конфы сделать в виде трейлера фильма или типа того.
Вопросы были по докладам в некоторых секциях. Выступления были от классных до неочень, как будто в некоторые секции поздно начали искать спикеров.
Довольно поздно узнали о конфе, хотя в одном городе находимся. Не хватило времени что-то прикольное придумать, обдуманно выделить бюджеты и ворваться.
Но в целом, впечатления хорошие) Спасибо!