«Как мы сократили срок разработки с года до четырех месяцев?» — сделали в три раза меньше функций, чем было запланировано изначально.
Получается, что проанализировали результат проектирования, сделали собственное проектирование и изменили функционал проекта. По факту сделали другой проект с другим набором функций.
Тут возникает много вопросов, которые влияют на восприятие статьи: кто делал первоначальное проектирование, кто делал новое проектирование, как согласовывали уменьшение функциональности в три раза и т.п. Не хватает контекста.
Отличное наблюдение! Вне трекера времени работы не остаётся. И важно учитывать один нюанс: я делал всю архитектуру проекта в одно лицо с нуля. И продолжаю делать. Началось всё в мае 2025. Это значит, уже скоро год будет.
Получается, что мне не нужно тратить время на то, чтобы во что-то въехать или что-то с кем-то согласовать. Во время каждого подхода к работе я косвенно затрагиваю разные участки системы и постоянно думаю над системными оптимизациями.
Например, мне при каждом новом подходе уже не нужно думать о каких-то атомарных элементах интерфейса — они уже все есть. Не нужно выдумывать новые модели, если старые хорошо работают.
Это счастье работы над проектом, где ты изначально полностью погружён в контекст. В клиентских проектах картина иная — я обычно несколько месяцев въезжаю в курс всего, выстраиваю систему в голове, дальше быстро делаю непосредственно проектирование и… обычно на этом моя работа заканчивается и нужно искать следующий проект :) Я называю это проклятием проектировщика-фрилансера. Очень хочется уже осесть в каком-нибудь постоянном проекте. Но пока это получилось сделать только в своём собственном.
Поэтому, в итоге, я действительно иногда обращаю внимание на свои физические ограничения, т.к. всё продумывание размазано по месяцам разрозненных задач.
За примером далеко ходить не надо. Возьмём эти последние 50 минут. Во время тестирования результата я заметил, что какие-то теги у меня написаны с заглавных букв, а какие-то со строчных, и что в разных частях интерфейса они могут отображаться по-разному. Это раздражало. Наблюдение и размышление, что с этим делать, заняло пять минут времени. Правки заняли ещё минут двадцать. Я уже на следующий день унифицировал отображение тегов во всех разделах, отображая их с заглавной буквы.
Спасибо, что не только написали по существу, но ещё и на соседнюю статью сослались. Очень приятно.
В конечном итоге в любом случае научусь работать с ветками, спасибо.
Про токены — это со слов друга. Как вам работа с Кодексом в IDE? Стоит заморочиться? У меня просто пока нет никаких нареканий к получившемуся подходу к работе. И обычно я действую по принципу «лучшее — враг хорошего». А потом — хоба! — и выясняется, что можно было делать то же самое значительно эффективнее :)
Начинал я проект не с Кодексом, а с ЧатомГПТ. Модель базы данных — это, скорее, моя работа. Технически её код по моей инструкции написал ЧатГПТ (и с тех пор она выросла раз в пять по параметрам), я же лишь слежу за тем, чтобы она была нормализована и проверяю параметры и дефолтные значения.
Лучше один раз увидеть, чем сто раз услышать. У меня такие вопросы:
Можете показать пример полноценной постановки по вашей методике для конкретной реально существовавшей и выполненной задачи?
В каком проценте постановок вы следуете всем собственным рекомендациям? В каком — лишь их части? В каком вообще забиваете на правила?
О каком размере команды идёт речь в вашем случае? Замечали ли какую-нибудь разницу в подходах в зависимости от сложности задач и количества участников?
Замечали ли разницу в подходах при работе с хорошо задокументированными системами (если вообще сталкивались с такими) и с системами без проектной документации?
Зависит от того, что втыкать. А вот записывать где-то для себя, какие именно плагины и для чего используются — это хорошая привычка. Проще поддерживать порядок, чем через пару лет разбираться в легаси.
Не знаю, как пропустил ваш вопрос О_о Для прототипов я использую Axure 8. Иногда приходится иметь дело с Фигмой. Для проектной документации (функциональные требования и функциональные спецификации) — гугл.доки. Картинки — это один из лучших способов передать информацию о том, что нужно сделать. Но без документов, описывающих логику работы, может возникнуть много вопросов.
Я тут как раз и подразумевал свод правил, используя слово «фреймворк». На самом деле сам же, получается, и нарушил свои правила: использовал термин, который не всем будет понятен, и не расшифровал его. Поправил этот момент, спасибо!
Можно делать выводы по себе, это один из подходов. В моём случае — это называется «экспертный аудит без привлечения респондентов». Более того, во многих случаях он оправдан. Например, вполне возможно, что вы правы, и действительно любой владелец СС знает своё поколение.
Я же, не являясь владельцем СС, всё-таки понаблюдал бы за людьми. Возможно, какой-нибудь молодой человек, не особо интересующийся машинами и получивший СС в наследство от родителей, не сможет ответить на вопрос, какого года машина и какие там были поколения. Или девушка, которой кто-то сделал такой дорогой и приятный подарок. Но это я фантазирую. Вполне возможно, окажется, что часть владельцев не интересовались историей автомобиля просто потому что не интересовались.
И, получается, статья не про другое. Она как раз про это. Так что спасибо за комментарий!
Воу, это было неприятно. Мне кажется, что одна из самых важных штук в общении — узнать контекст и детали, а уже потом делать выводы.
Например, как вы выразились, «программеры-рукожопы». Я аудировал сайт мирдворников.ру, я его не разрабатывал. Программером-рукожопом, получается, вы называете автора этого проекта. Сегодня он генеральный директор этой компании, а в 2009 году, да, своими руками делал интерфейс. Вот даже можно на веб-архиве убедиться, что именно этот элемент интерфейса появился 16 лет назад (https://web.archive.org/web/20100109111232/https://www.mirdvornikov.ru/) и с тех пор не сильно поменялся.
Чел, который «с умным видом рассказывает, как ему плевать на мнение пользователя» — это я, UX-дизайнер, а не разработчик. И моя задача — не «сделать тяп-ляп» интерфейс, а провести аудит существующего интерфейса, чтобы порекомендовать его улучшения. И суть статьи в том, что я сначала рекомендую исправлять те вещи, которые мешают пользователям достигать целей. А не те, которые кажутся им неудобными или некрасивыми. Кстати, иногда совпадает так, что это одни и те же вещи. Но это редко.
Вы сравниваете себя с профильным фронтендером, но, получается, что сайт делал не профильный фронтендер. И делал 16 лет назад. Возможно, это и будет ответом на вопрос «почему» вы сделали так, а в этом проекте сделано иначе.
Согласен, конечно делать надо всё нормально сразу. Если бы так делали, то моя услуга по аудиту и не нужна бы была, верно?
На самом деле вы своим комментарием поднимаете гораздо больше тем. Например, должен ли клиент, который действительно нанимает разработчиков, разбираться в их работе достаточно хорошо, чтобы замечать ошибки и обращать на них внимание?
Или вот, например, «найти хороший пакет для фильтра с поиском». У меня была история, когда я в собственный стартап встраивал визуальный редактор для текста. И думаете разрабы мне предложили несколько вариантов на выбор и проконсультировали, какой из них подойдёт в моём случае? Нет, как раз они использовали тот, с которым однажды работали в прошлом. Правильный ли это подход? И вообще — их ли это задача и зона ответственности?
Где-то разработчики принимают все эти решения самостоятельно, где-то они делают ровно то, что их попросили на основе проектной документации, прототипов и макетов в Фигме. Где-то проект делается для себя своими руками. Везде будут разные подходы и истории.
Вот вы свой проект в пример ставите. А мы же о нём ничего не знаем. Это тоже что-то коммерческое с тысячами покупателей? Вы его тоже делали в 2009-м и нашли нужное решение в те времена? Какими бы ни были ваши ответы — они и будут самым интересным и полезным в беседе. И, собственно, основой для этой самой беседы.
Мы прямо сейчас находимся на странице с примером. Под статьёй — список комментариев. Под списком комментариев — форма добавления нового комментария. Если поставить в неё автофокус, то страница будет автоматически быстро пролистываться до формы, мешая вам читать статью.
А так-то вы правы — на десктопе автофокус в первом поле действительно чаще помогает, чем мешает. И если бы форма располагалась сразу в первом экране (и это был бы десктоп, плюс в силе все те нюансы, которые я перечислил в статье), я бы, скорее всего, сам поставил автофокус.
Но если форма, например, находится внизу длинной страницы, автофокус может неожиданно перехватывать управление и мешать дочитать текст до конца. Важно не то, что он чаще помогает — важно, что вариант без автофокуса безопаснее в большем числе контекстов.
Спасибо вам — благодаря вашему комментарию и моему ответу я понял, что в статье не хватало этого нюанса, и дополнил её. Статья стала лучше.
Если форма находится внизу страницы из трёх экранов (например, на лендинге с формой захвата в конце), вы же не будете слать лучи неодобрения тем, кто не поставит автофокус в её первое поле?
«Как мы сократили срок разработки с года до четырех месяцев?» — сделали в три раза меньше функций, чем было запланировано изначально.
Получается, что проанализировали результат проектирования, сделали собственное проектирование и изменили функционал проекта. По факту сделали другой проект с другим набором функций.
Тут возникает много вопросов, которые влияют на восприятие статьи: кто делал первоначальное проектирование, кто делал новое проектирование, как согласовывали уменьшение функциональности в три раза и т.п. Не хватает контекста.
Отличное наблюдение! Вне трекера времени работы не остаётся. И важно учитывать один нюанс: я делал всю архитектуру проекта в одно лицо с нуля. И продолжаю делать. Началось всё в мае 2025. Это значит, уже скоро год будет.
Получается, что мне не нужно тратить время на то, чтобы во что-то въехать или что-то с кем-то согласовать. Во время каждого подхода к работе я косвенно затрагиваю разные участки системы и постоянно думаю над системными оптимизациями.
Например, мне при каждом новом подходе уже не нужно думать о каких-то атомарных элементах интерфейса — они уже все есть. Не нужно выдумывать новые модели, если старые хорошо работают.
Это счастье работы над проектом, где ты изначально полностью погружён в контекст. В клиентских проектах картина иная — я обычно несколько месяцев въезжаю в курс всего, выстраиваю систему в голове, дальше быстро делаю непосредственно проектирование и… обычно на этом моя работа заканчивается и нужно искать следующий проект :) Я называю это проклятием проектировщика-фрилансера. Очень хочется уже осесть в каком-нибудь постоянном проекте. Но пока это получилось сделать только в своём собственном.
Поэтому, в итоге, я действительно иногда обращаю внимание на свои физические ограничения, т.к. всё продумывание размазано по месяцам разрозненных задач.
За примером далеко ходить не надо. Возьмём эти последние 50 минут. Во время тестирования результата я заметил, что какие-то теги у меня написаны с заглавных букв, а какие-то со строчных, и что в разных частях интерфейса они могут отображаться по-разному. Это раздражало. Наблюдение и размышление, что с этим делать, заняло пять минут времени. Правки заняли ещё минут двадцать. Я уже на следующий день унифицировал отображение тегов во всех разделах, отображая их с заглавной буквы.
Спасибо, что не только написали по существу, но ещё и на соседнюю статью сослались. Очень приятно.
Спасибо. Век живи — век учись. Погуглю все эти штуки.
Вы хотите сказать, что перевод статьи на другой язык будет обладать признаками текстов, сгенерированных нейронками?
В моём случае важны новые навыки. Я всё это проделывал впервые и многому научился. Так что ни о чём не жалею.
Понял, принял, спасибо за опыт!
В конечном итоге в любом случае научусь работать с ветками, спасибо.
Про токены — это со слов друга. Как вам работа с Кодексом в IDE? Стоит заморочиться? У меня просто пока нет никаких нареканий к получившемуся подходу к работе. И обычно я действую по принципу «лучшее — враг хорошего». А потом — хоба! — и выясняется, что можно было делать то же самое значительно эффективнее :)
Начинал я проект не с Кодексом, а с ЧатомГПТ. Модель базы данных — это, скорее, моя работа. Технически её код по моей инструкции написал ЧатГПТ (и с тех пор она выросла раз в пять по параметрам), я же лишь слежу за тем, чтобы она была нормализована и проверяю параметры и дефолтные значения.
Лучше один раз увидеть, чем сто раз услышать. У меня такие вопросы:
Можете показать пример полноценной постановки по вашей методике для конкретной реально существовавшей и выполненной задачи?
В каком проценте постановок вы следуете всем собственным рекомендациям? В каком — лишь их части? В каком вообще забиваете на правила?
О каком размере команды идёт речь в вашем случае? Замечали ли какую-нибудь разницу в подходах в зависимости от сложности задач и количества участников?
Замечали ли разницу в подходах при работе с хорошо задокументированными системами (если вообще сталкивались с такими) и с системами без проектной документации?
Зависит от того, что втыкать. А вот записывать где-то для себя, какие именно плагины и для чего используются — это хорошая привычка. Проще поддерживать порядок, чем через пару лет разбираться в легаси.
Прикол. Это скриншоты из чата проекта.
А это из нового чата, не связанного с проектами:
Видимо, какой-то непонятный частный случай.
Ух ты! Интересно, как это понимать?
Не знаю, как пропустил ваш вопрос О_о
Для прототипов я использую Axure 8. Иногда приходится иметь дело с Фигмой.
Для проектной документации (функциональные требования и функциональные спецификации) — гугл.доки.
Картинки — это один из лучших способов передать информацию о том, что нужно сделать.
Но без документов, описывающих логику работы, может возникнуть много вопросов.
Я тут как раз и подразумевал свод правил, используя слово «фреймворк». На самом деле сам же, получается, и нарушил свои правила: использовал термин, который не всем будет понятен, и не расшифровал его. Поправил этот момент, спасибо!
Можно делать выводы по себе, это один из подходов. В моём случае — это называется «экспертный аудит без привлечения респондентов». Более того, во многих случаях он оправдан. Например, вполне возможно, что вы правы, и действительно любой владелец СС знает своё поколение.
Я же, не являясь владельцем СС, всё-таки понаблюдал бы за людьми. Возможно, какой-нибудь молодой человек, не особо интересующийся машинами и получивший СС в наследство от родителей, не сможет ответить на вопрос, какого года машина и какие там были поколения. Или девушка, которой кто-то сделал такой дорогой и приятный подарок. Но это я фантазирую. Вполне возможно, окажется, что часть владельцев не интересовались историей автомобиля просто потому что не интересовались.
И, получается, статья не про другое. Она как раз про это. Так что спасибо за комментарий!
Воу, это было неприятно. Мне кажется, что одна из самых важных штук в общении — узнать контекст и детали, а уже потом делать выводы.
Например, как вы выразились, «программеры-рукожопы». Я аудировал сайт мирдворников.ру, я его не разрабатывал. Программером-рукожопом, получается, вы называете автора этого проекта. Сегодня он генеральный директор этой компании, а в 2009 году, да, своими руками делал интерфейс. Вот даже можно на веб-архиве убедиться, что именно этот элемент интерфейса появился 16 лет назад (https://web.archive.org/web/20100109111232/https://www.mirdvornikov.ru/) и с тех пор не сильно поменялся.
Чел, который «с умным видом рассказывает, как ему плевать на мнение пользователя» — это я, UX-дизайнер, а не разработчик. И моя задача — не «сделать тяп-ляп» интерфейс, а провести аудит существующего интерфейса, чтобы порекомендовать его улучшения. И суть статьи в том, что я сначала рекомендую исправлять те вещи, которые мешают пользователям достигать целей. А не те, которые кажутся им неудобными или некрасивыми. Кстати, иногда совпадает так, что это одни и те же вещи. Но это редко.
Вы сравниваете себя с профильным фронтендером, но, получается, что сайт делал не профильный фронтендер. И делал 16 лет назад. Возможно, это и будет ответом на вопрос «почему» вы сделали так, а в этом проекте сделано иначе.
Согласен, конечно делать надо всё нормально сразу. Если бы так делали, то моя услуга по аудиту и не нужна бы была, верно?
На самом деле вы своим комментарием поднимаете гораздо больше тем. Например, должен ли клиент, который действительно нанимает разработчиков, разбираться в их работе достаточно хорошо, чтобы замечать ошибки и обращать на них внимание?
Или вот, например, «найти хороший пакет для фильтра с поиском». У меня была история, когда я в собственный стартап встраивал визуальный редактор для текста. И думаете разрабы мне предложили несколько вариантов на выбор и проконсультировали, какой из них подойдёт в моём случае? Нет, как раз они использовали тот, с которым однажды работали в прошлом. Правильный ли это подход? И вообще — их ли это задача и зона ответственности?
Где-то разработчики принимают все эти решения самостоятельно, где-то они делают ровно то, что их попросили на основе проектной документации, прототипов и макетов в Фигме. Где-то проект делается для себя своими руками. Везде будут разные подходы и истории.
Вот вы свой проект в пример ставите. А мы же о нём ничего не знаем. Это тоже что-то коммерческое с тысячами покупателей? Вы его тоже делали в 2009-м и нашли нужное решение в те времена? Какими бы ни были ваши ответы — они и будут самым интересным и полезным в беседе. И, собственно, основой для этой самой беседы.
Мы прямо сейчас находимся на странице с примером. Под статьёй — список комментариев. Под списком комментариев — форма добавления нового комментария. Если поставить в неё автофокус, то страница будет автоматически быстро пролистываться до формы, мешая вам читать статью.
А так-то вы правы — на десктопе автофокус в первом поле действительно чаще помогает, чем мешает. И если бы форма располагалась сразу в первом экране (и это был бы десктоп, плюс в силе все те нюансы, которые я перечислил в статье), я бы, скорее всего, сам поставил автофокус.
Но если форма, например, находится внизу длинной страницы, автофокус может неожиданно перехватывать управление и мешать дочитать текст до конца.
Важно не то, что он чаще помогает — важно, что вариант без автофокуса безопаснее в большем числе контекстов.
Спасибо вам — благодаря вашему комментарию и моему ответу я понял, что в статье не хватало этого нюанса, и дополнил её. Статья стала лучше.
Если форма находится внизу страницы из трёх экранов (например, на лендинге с формой захвата в конце), вы же не будете слать лучи неодобрения тем, кто не поставит автофокус в её первое поле?
Я исхожу вот из чего: если рекомендация не навредит в большем количестве сценариев — она более универсальна.