Alex Yashin
У вас там там сельский проект мобильного приложения? Нормальный Global Template команда аналитиков пишет год.
Чувак, я правильно понимаю что единственное, что у тебя в итоге хорошо получается - это дизайн интерьера? Так может именно этим и стоило заниматься? В звукозаписи ты не сечёшь, в бизнесе ничего не понимаешь (как сам говоришь), но кресла - прикольные и ручки дверные - норм. Может надо было заниматься дизайном квартир и студий?
Ахахаха, единственное что вы смогли ответить это вылепить мне минус? Вот это я понимаю - горящий бэкэнд :)
Угу. Будет очень обидно, когда эта картинка из-за вашей кривой дыры, которую вы без ТЗ как-то непонятно пробурили, упадёт на пол, сломается и прекратит существование. Обосратушки будут.
К примеру если пользовательские данные утекут из-за того что вы об этом не подумали и в ТЗ не вписали. Можно в лёгкую хапнуть проблем на миллионы долларов из-за вашего вшивого приложения за 500к рублей
Угу. Если есть ТЗ (а оно скорее всего динамическое, где отражаются все правки и актуальные версии), то имея его на руках у нас студент-практикант за неделю пишет User Manual. Как его писать пез проектной документации я хз. Это получается надо по новой анализировать весь готовый софт.
Какая-то гора. Мне это ни о чем не говорит, скорее всего вы мелкая сошка. Ваши типовые проекты я из статьи не вижу. Поэтому пишу: "не знаю где работаете вы."
Школота??? Да я знаю одного пятидесятилетнего мудака, который так делает. Мы так смету и сроки в пять раз превысили с этим любителем работать без ТЗ.
У клиента карьера в фирме по бороде пошла, а программисты поувольнялись с нервным срывом.
А этот мудак счастлив и продаёт такие проекты дальше.
Так в нормальном ТЗ уже есть дизайн. Зачем он отдельно?
Если бы заказчик знал чётко - он бы строил сам. На это у него нет лишних мощностей, он оптимизирован.
Но если он чётко не знает - это вовсе не означает что можно делать что угодно. Дырки нужны определённой глубины, конкретного диаметра, строго в необходимых координатах. И не дырки, а отверстия. Кто-то должен изучить материал стен, подобрать подходящие свёрла и дрели, взвесить картину, выбрать соответствующие дюбеля, прописать программу тестов на устойчивость и записать это в ТЗ. Ни заказчик, ни разработчик этому не обучены и не обладают лишним временем на это. Без ТЗ получается не установка картины на стену, а бурение волосатой дыры кожаным сверлом.
Это у вас 99% проектов - мелочь. А у людей имеющих понятие о Project Management, основные проекты - крупные. Мелочь нам даже создание своей песочницы не окупит, про обучение персонала я вообще молчу
Как у вас заказчик может сказать: я хотел другой интерфейс, если он подписывал ТЗ, где есть макет?
А вы видели в своей жизни 100 ТЗ?
У меня стаж десять лет и я почему-то не видел столько. Видел наверное пару десятков, большую часть из которых сам писал или принимал участие в написании. И они в массе своей почему-то были нормальными. С какими мудаками вы работаете, если у вас такая низкая квота хороших ТЗ?
(Табличка Сарказм)
Это нормальный проект и так выглядит нормальная задача. Я не знаю где работаете вы, но мы ничего проще роллаута не делали.
Создание любого инструмента - сложнее. Если ваш потолок это интерфейс на уже готовый функционал, то тут реально ТЗ не нужен (и то надо обговаривать корпоративные цвета, шрифты, отображение пользовательского соглашения и прочее). Плюс надо прописывать из какой таблицы мы берём, куда кладём и через какой интерфейс мы это делаем. Это в любом случае надо записать при сдаче проекта, иначе этим софтом невозможно будет пользоваться. Так если это в любом случае надо писать, почему не написать сразу в ТЗ?
По разному занимает, в зависимости от уникальности. Если проект стандартный - у нас естественно есть наработки. Как-то мы внедряли новый бухгалтерский стандарт сразу на 50 стран, там базовый ТЗ писали год с юристами, аудиторами и IT материнского концерна и на его основе писали ТЗ под каждую страну от пары месяцев до года. Потом это всё внедрялось, тестировалось и запускалось в эксплуатацию. Проект в среднем на пять лет, участвовали тысячи людей. Вы предлагаете делать это без ТЗ? Начинать без ТЗ?
Пока ты работаешь без ТЗ - ты работаешь в пустую.
На маленьких проектах, где не надо ничего учитывать и ТЗ пишется быстро. Чего там писать, если учитывать нечего?
Ок, есть идея, пример из реальной работы. Надо внедрить НДС в банковские услуги. Всё. Вот вся идея. Не в пользовательское приложение банка, а в принципе в весь банк. До принятия соответствующего закона НДС в банке в принципе не существовал. Как вы реализуете это пользовательскими экранами?
Создаётся ощущение, что ничего сложнее пользовательских интерфейсов вы не делали. У вас и заказчик какой-то неведомый существует, хотя на практике ты бегаешь по отделам месяцами и выясняет кто каким образом затронут. От маркетинга до юридического департамента через бухгалтерию и прописываешь кто затронут, какие у них требования к продукту и какие ограничения накладывает каждый участник. Прописываешь ты это (барабанная дробь) в ТЗ.
А пользовательские экраны ваши это бантики, которые большую часть участников вообще не интересуют. IT хочет знать как выглядит поток данных в системе, бухгалтеры хотят привязку к счетам, юристы хотят соблюсти Compliance. И всё это надо учитывать и нельзя ни отразить в пользовательских экранах, ни переделать в конце. В отличие от вашего UI, который можно по три раза в неделю переписывать без значительных усилий.
Способ начинать с макетов - прекрасен, если у клиента в принципе есть понимание как должен работать софт. Тогда именно на основании прототипирования мы ТЗ и пишем.
Но чаще у клиента в голове есть потребность, то-есть функционал и он понятия не имеет какие кнопочки ему нужны в приложении.
Типичный пример: "нам надо реализовать НДС в услугах нашего банка" и всё и думай теперь. Клиент понятия не имеет, нужно ли ему пользовательское приложение в принципе для реализации этой задачи.
Это и есть процесс написания ТЗ, гений вы наш! Вы ТЗ с потолка что ли берёте или всё-таки заказчика спрашиваете чего он хочет? А принимает у вас ТЗ заказчик не глядя?
Ой какое чудное ТЗ на нас с неба упало... Так это по вашему выглядит?
Почему у нас в ТЗ десятилетней давности были и дизайн экраны и ETL процессы и функционал каждой кнопки? Может вы просто ТЗ писать не умеете?
А как вы без ТЗ архитектуру системы пропишете? Вы открыли Америку и придумали ТЗ с картинками в 2021 году?
На базе двухдневного говнокурса от scrum academy.
Как же я вертел этот скрам. Скрам мастер Райфайзен банка, посмотрите на него. Двухдневный курс он посетил и разглагольствует. На Product-Owner-a мозгов не хватило? Весь этот скрам придумали по причине абсолютно некомпетентного менеджмента, вот таких скрам мастеров. Как бы нам лизать клиенту зад и при этом в три раза раздуть бюджет? AGILE!
Дмитрий Бабак - за пять лет в университете научился гуглить. Успешный успех.