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

Рассказ веду от лица основателя Проектората — бренда, объединившего самостоятельных проектировщиков/UX-дизайнеров.

Речь идёт исключительно о новых проектах, а не доработках в существующие. Самый распространённый сценарий выглядит так. Человек придумывает идею для своего продукта и решает его разработать. Он ищет по знакомым контакты программиста. Находит и в двух словах объясняет ему задачу. Программист тыкает пальцем в небо и называет стоимость разработки. Допустим, два миллиона. И намекает, что оценка примерная и было бы неплохо посмотреть на техническое задание.

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

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

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

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

Привет читателям! Меня зовут Владимир Маркиев, но сегодня зовите меня Александр Сергеевич, я — технический писатель в компании, которую нельзя называть. Когда компания, которую нельзя называть, создавала онлайн-документацию при помощи Antora, стояла задача оставить место, куда в будущем интегрируется список накопительных изменений.

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

Привет всем!

В этой статье говорится о том, как я конспектирую на компьютере, а точнее описываются способы ускорения набора LaTeX-овского текста.

Код может быть красивым сам по себе, но графическое представление не помешает.

Вот уже второй год, как мы используем XWiki, вместо Confluence. 

За это время я к ней привык и даже в некотором роде полюбил. Поэтому не могу пройти мимо такого важного события как выход новой LTS версии 14.10.2.

Если вы не знакомы с релизным циклом XWiki, то вас может удивить, что LTS версия выходит в конце года и в течение всего следующего года получает обновления. Иногда бывает так, что обновления версии XWiki, что-то правит и одновременно что-то ломает, но в целом как обновление того стоит. Например, в 14 версии неплохо улучшили работу с вложениями, экспортом PDF и диалогом вставки изображений в редакторе.

Сегодня я не буду вдаваться в технические подробности, а просто сделаю беглый обзор функционала, рассчитанный в первую очередь на людей только что узнавших об XWiki. Обозревать мы будем самую последнюю на текущий момент версию 14.10.2 со Standard Flavor, установленную через Docker образ.

29-30 ноября прошла конференция для аналитиков FlowConf 2022. Основная особенность конференции — ее ориентация на конкретные практические рецепты. Одним из направлений, которое содержит много таких рецептов, стал Docs As Code или, в более широком смысле, DocOps в работе аналитика. В посте представляю обзор этого направления.

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

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

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

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

Хотелось бы вспомнить одну из парадигм Agile " Работающий продукт важнее исчерпывающей документации ", но в данном случае это не наша история, поэтому сегодня поговорим немного о ГОСТах.

Стоит сделать небольшое лирическое отступление и начать с формального определения:

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

Продолжаем тему оформления документов по ГОСТам, начатую в статье «Оформляем приложения по ГОСТ 7.32 в MS Word и не только». На этот раз рассматриваем подходы к автоматизации форматирования больших текстов (более 500 страниц) в редакторе MS Word. Предлагаемые подходы применимы также в других редакторах, использующих стили, в частности, LibreOffice Writer.

Иногда хочется разбавить свои публикации чем-то легким и незамысловатым. И вот как раз подвернулся повод. Намедни я закончил большой онлайн курс в Нетологии и готов поделится с вами ощущениями.

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

Сегодня я:

 -поделюсь с вами ощущениями от обучения в целом;

- кратко пробегусь по каждому курсу в специализации;

- отвечу на вопрос: “Что дает обучение?“.

Уже довольно давно, более 3 лет, работаю юристом в ИТ-компании. До этого имел обширный юридический опыт как в ИТ, так и в других сферах.

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

Рассказал о своей работе коллегам, а теперь подумалось, что, возможно, это будет интересно и кому-то за пределами нашей компании.

Почему же надо дружить с ваши юристом и чем он может быть вам полезен?

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

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

И так, поехали – 8 классических способов сделать вашу документацию ненавистной для пользователя.

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

Документация живёт и побеждает

В этой статье на реальном кейсе я хочу рассмотреть весь путь превращения требований от бизнес-заказчика в техническое задание для разработчиков. Кроме того, в отдельных врезках я буду приводить объяснение той или иной технологии, того или иного понятия на доступном языке — для чайников (сама таким была и очень хотела, чтобы мне кто-то на пальцах объяснил все).

Итак, начнем.