Всё о деятельности технических писателей
Обзорная статья о QPR Enterprise Architect. Основные возможности и преимущества данного инструмента.
Л - Добрый день, дорогие зрители, сегодня мы продолжаем нашу серию репортажей «Стартаперы Кварцевой Лощины». С вами снова я, независимый журналист, Лайер Бала-Больё, и сегодня наш гость - талантливый селфмейд, добившийся всего сам, 19-летний сын известного миллиардера, стартапер Жу̒лико Бары̒гги младший.
Жулико уже выпустил два сверхполезных и сверхнужных приложения, это всем известный SriiPee для заказа пиццы прямо с унитаза и HeyGey – апп для поиска скоплений бородатых мужчин в клетчатых рубашках, любящих фруктовые коктейли и самокаты. Последнее приложение даже автоматически предустанавливается в каждый новый грушефон.
Жулико, вы только что были спикером на проходящем в Сан-Дьябло Блаблатоне и упомянули такую интересную вещь, как ШвабрОпс - можете рассказать нашим зрителям, что это такое и с чем его едят.
Ж – Привет, Лайер, привет всем. Да, на Блаблатоне я рассказывал про ШвабрОпс – это новое перспективное направление в IT. Дело было так. Я маялс…т.е. интенсивно работал в офисе и обратил внимание, что какой-то очкастый толстый задрот ходит туда-сюда из кабинета в кабинет. Я спросил секретаршу – кто это такой? Она ответила – это наш ДевОпс.
Л – Ага.
Ж – А я, если честно, даже не знаю, кто это такой. Но мне тут же в голову пришла идея. А что, если он возьмет в руки швабру и будет протирать пол, пока ходит туда-сюда.
Л – Угу.
Ж – Ну и все, собственно. Я подумал-подумал и решил – а зачем нам уборщица?! Пусть этот дев…как его там…в общем – пусть он еще и пол протирает параллельно. Это же какая экономия получается!
Техническая документация — важный элемент любого сообщества, в том числе при продвижении продукта. Документация является средством первого прямого контакта с разработчиками и пользователями, заинтересованными в использовании продукта. Чем лучше документация, тем больше шансов, что они вернутся и будут участвовать в жизни сообщества. В этой статье рассмотрим распространенные ошибки, которые можно допустить при создании документации.
О будущем системных аналитиков, о ChatGPT и LLM, что не заменит аналитиков, слишком большом списке требований, что добавить в резюме, low-code/zero-code системах, стажировках и ветках прокачки, поговорили с Алексеем Лобзовым, руководителем направления развития компетенции системного анализа в Альфа-Банке.
Всем, привет! Меня зовут Алёна Барыкина и я методолог отдела информационного моделирования департамента цифровизации инвестиционно-строительных проектов компании "Bimeister". И сегодня, хочу с вами поделиться важным аспектом исполнения желаний в проектной деятельности с использованием цифрового информационного моделирования
Вы, конечно же, знаете ключевой принцип успеха любого проекта, включая создания цифровой информационной модели (ЦИМ) - «Начинай только тогда, когда результат уже в уме». Выражение, которое отражает саму суть любой проектной деятельности.
Только вот вопрос - а что каждый участник процесса понимает под необходимым результатом в проекте создания цифровой информационной модели?
Создание ЦИМ – это очень сложный и дорогостоящий процесс, в котором задействован большой круг специалистов. И каждого из них волнуют свои вопросы. Здесь очень важно найти совместное оптимальное решение, чтобы получить тот продукт, который отвечает запросам в области возможностей использования цифровой информационной модели, уровня ее проработки, а так же полноты наполнения информацией.
Когда Заказчик говорит, что ему нужна цифровая информационная модель, он говорит не просто о модели, а о преимуществах, которые он хочет получить с помощью ЦИМ:
Давай определим, зачем это вообще нужно?
Эта статья рассказывает о том, как можно тестировать документацию и вероятно кому то поможет сделать этот процесс в своей команде более качественным
Если вы знакомы с подходом к документированию, предложенным Саймоном Брауном, вы могли заинтересоваться им, но, возможно, задавались вопросом о его реализации. Этот репозиторий заполняет пробел, представляя конкретный шаблон реализации подхода, который состоящего из:
Предполагается хранение этой документации в репозитории и работа с ней так же, как и с кодом.
Документацию рядом с кодом мы ведём уже 6 лет, она делится по слоям: фронт, миддл и бэк. С миддлом всё хорошо, а вот с фронт-документацией всё портят изображения экранных форм. От них репозиторий раздувается, как ипотечный пузырь на льготных ставках.
Но, кажется, эту напасть удалось побороть. В статье я расскажу, как вести фронтовую документацию рядом с кодом и к каким последствиям это приводит.
Хабр, привет! В прошлой статье про UML мы узнали что такое язык моделирования UML, зачем он нужен, основные плюсы и минусы UML, а также рассмотрели диаграмму классов. Сегодня я хочу продолжить тему проектирования процессов и остановиться на диаграмме компонентов.
«....всё это действенные методы для улучшения разработки интересной и эффективной технической документации....»
Postman в основном известен в качестве мощного инструмента для тестирования API. Но он также может значительно облегчить жизнь новым членам команды, аналитикам и клиентам, которые интегрируются с вами.
В этой статье я, SDET-специалист SimbirSoft Дарья, проведу обзор функций, с помощью которых Postman может помочь каждой из этих групп. Покажу на небольших примерах, как превратить набор запросов в то, что не стыдно будет пошарить коллегам, взаимодействующим с вашим API, и упростит жизнь новоприбывшим членам команды. Эта статья будет полезна специалистам различных уровней как в ручном, так и в автотестировании, а также бизнес- и системным аналитикам, для которых Postman сможет быть полезным для работы с документацией.
Примеры буду приводить на ставшем классикой тренажере для практики отправки REST-запросов Petstore Swagger. Это имитация онлайн-зоомагазина, где можно манипулировать информацией о питомцах пользователей, а также создавать заказы.
Документация в рамках ИТ-проекта/продукта подчас имеет необычное исполнение. Есть проекты/продукты, где на первый взгляд с документацией всё хорошо, она выходит в рамках обязательств по контракту, но вот применять её очень сложно. Бывают и обратные примеры, когда документация оформлена отлично и написана грамотно, в ней всё понятно, но она очень сильно устарела. Иногда случается всё и сразу.
Не всегда понятно, как включить нового сотрудника в работу? Новичку приходится отвлекать более опытных коллег. Самый удивительный случай, это когда в ИТ-проекте/продукте существует свой мифический «Петрович», который знает, что как устроено, и может помочь освоиться.
Привет! Меня зовут Андрей Гладилин, я работаю в Swordfish Security над составлением технической документации для ИТ-решений. Завершая предыдущую статью, мы обсудили преимущества и недостатки DocOps-подхода к разработке технической документации и немного поговорили о прикладной реализации этой парадигмы — Doc-as-code.
Позволю себе напомнить, что основная идея DocOps заключается в том, что создание технической документации осуществляется в тесном контакте с разработкой программного продукта и во многом «отзеркаливает» этапы последней — рабочие процессы максимально синхронизируются и объединяются в общую систему, широко применяется автоматизация рутинных операций и упрощается совместная работа, что позволяет повысить общую эффективность процесса.
Теперь перейдем к практической реализации DocOps-решения, которое мы начали обсуждать в первой части статьи.
Разработка — сложный процесс. Причем часто за сложностью непосредственной реализации проекта скрывается и сложность планирования всех этапов разработки, учета взаимосвязей, зависимостей и других критериев. Нередки случаи, когда ошибки на этапе планирования, например, внедрения новой функции, обходятся дороже, чем проблемы в проде. Исключить подобные риски помогает практика проведения технического анализа.
Меня зовут Евгений Шалаев. Я Frontend-разработчик в команде СберЗдоровье. В этой статье я расскажу о теханализе в разработке, его пользе, принципах выполнения и своем опыте проведения подобных исследований.
Вот такой дружной и весёлой командой стартовал новый проект, в котором потом «друзья» не смогли договориться.
История о том, почему необходимо поддерживать деловую коммуникацию с исполнителем, а также вести документацию на проекте.
Простые истины с высокой ценой ошибки.
Так уж вышло, что в течение своей деятельности мне немало доводилось работать с публичными API, причем как в со стороны, которая их предоставляет, так и со стороны, которая интегрируется. И здесь я хочу рассказать не только про один из кейсов, который решал ранее, но и поделиться результатами проводимого анализа, полученным опытом, а также набитыми шишками.
Материала вышло многовато, поэтому разбил его на 2 части. В части 1 (этой статье) рассмотрим, почему и зачем вообще публичным API нужна документация, есть ли у нее какие-то отличия от документации внутренних API, а также проанализируем и детально разберем различные подходы к ведению такой документации, попутно познакомившись поближе с полезными инструментами.
В следующей части затронем уже непосредственно написание документации, подумаем, кто же должен ее писать, какие инструменты могут в этом помочь, как это встроить в реальный процесс разработки и что во всем этом может пойти не так.
Лучший способ понять теорию — получить больше опыта в разных проектах. Для системных и бизнес‑аналитиков я постоянно показываю подходы к работе через публикацию разборов задач: БД, API, Интеграции, требования, и все, что связано с проектированием систем.
После публикации поста общий подход к работе с задачами системного аналитика, меня попросили показать, как его применить на практике. Собрала примеры постановок задач и описаний системы по одному из проектов. Здесь постараюсь кратко изложить его. А в конце оставлю ссылку на подборку примеров, которые можно посмотреть и переиспользовать в своих проектах.
Не первый год я составляю слова из букв и создаю из них тексты и код. Сейчас хочется просто поразмышлять об этом, не оставаясь до конца серьезным.
При запуске чековой промоакции с геймификацией, особенно если вам нужно разработать сайт с игровым контентом и функционалом аукционного сайта, необходимо составить подробное техническое задание (ТЗ) для программистов. В этой статье мы расскажем, как правильно составить ТЗ для такого проекта.