Управление проектами *

Среда общих данных (СОД), как основополагающая часть технологий информационного моделирования (ТИМ), прочно заняла важное место в цепочке процессов цифровизации строительной отрасли.

Среда общих данных (СОД) - это программно-технический комплекс для совместной работы всех участников проекта с информационными моделями на всех стадиях жизненного цикла.

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

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

Требования составлены на основе многолетней практики работ с СОД различных вендоров и с учетом положений всех действующих национальных и мировых нормирующих документов, таких как:

Мой канал - https://t.me/tidy_mng

Принцип MECE (Mutually Exclusive, Collectively Exhaustive) — это один из ключевых подходов, широко применяемых в консалтинге, аналитике и управлении. Этот метод помогает систематизировать данные, разбивая их на независимые категории, которые охватывают все аспекты рассматриваемой проблемы.

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

Планирование — важная задача не только для тимлида или менеджера. Часто разработчику приходится отвечать на вопрос «когда это будет готово?».

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

Вопрос о необходимости документации при разработке вызывает много споров. В динамичном мире IT, где изменения стремительны, я часто слышал холиварные обсуждения: а так ли необходима документация?

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

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

UML, парадокс Тога, спасение провального проекта, типология РП, делегирование, «слово пацана» и всё интересное, что писали на этой неделе про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные.

Читайте, сохраняйте и применяйте!

Меня зовут Артем! Я проектный менеджер студии разработки CORE. Мы разрабатываем программное обеспечение для бизнеса. В основном, мелкие CRM и ITSM решения, которые включают функционал, не реализованный в крупных продуктах.

Анализ трудов [О’Коннэл, 2005; Черников, Дашицыренов, 2017; Марченко и др., 2020; Базарова, Рочев, 2022] позволил установить, что основными технологическими свойствами ИТ-продуктов являются инкрементность и высокая технологичность.

Инкрементность ИТ-продуктов заключается в возможности добавления в программный код новых данных и команд с целью расширения функциональных возможностей и исправления программных ошибок (bug). Ярким примером инкрементности является компьютерная игра Cyberpunk 2077, выпуск которой состоялся в конце 2020 года. Несмотря на относительную давность релиза итоговой версии игры, организация-разработчик CD Projekt RED систематически выпускает обновления, улучшая технические характеристики, исправляя ошибки и добавляя новый контент. Например, в сентябре 2022 года разработчик выпустил патч 1.6, где был добавлен контент сериала Cyberpunk: Edgerunners, премьера которого состоялась осенью 2022 года на Netflix.

Инкрементность дает возможность декомпозировать желаемый ИТ-продукт на отдельные пользовательские истории (user stories) и по частям поставлять их заинтересованным сторонам. Как отмечают в своих трудах К. Вигерс и Д. Битти, заинтересованные стороны очень часто предъявляют большое количество противоречивых пользовательских, функциональных и бизнес-требований, которые легко устраняются за счет инкрементности. В частности, она позволяет сначала создавать пользовательские истории, которые удовлетворяют требованиям всех сторон, а затем, от обновления к обновлению, постепенно устранять критические противоречия [Вигерс, Битти, 2022].

Представьте, что вы, к примеру, директор по цифровому развитию крупного бизнеса, и вам нужно защитить перед начальством условия договора с IT-интегратором. Предполагаю, выбирая из вариантов Fixed Price, Time & Material или Retainer, вы остановитесь на каком-то из первых двух типов контракта. Еще бы – один обещает бюджет без “сюрпризов” и предполагает контроль по заданному плану, другой – предоставляет гибкость и свободу действий.

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

Самое важное, что характеризует любого менеджера — это то, как он выдерживает собственные обещания. Не то, как он их дает, а то, как выдерживает.

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

Чем он управляет: одной задачей, целым проектом или портфелем проектов на миллиард — пофигу. Слово дал — иди делай, на тебя рассчитывают. Слово дать не можешь? Пойди еще подумай и дай, тебя набрали не для нытья, а для решения проблем.

Это статья про базовый софтскилл который касается и менеджеров и исполнителей: про умение нести отвественность. Если вам интересна тема софтскиллов, читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал «Морковка спереди, морковка сзади».

Всем прекрасного вторника, коллеги! 

Сейчас 11 ноября - пик кленовой шуршальности и срок когда стоило бы закрыть работы по строительству, потому что  строить под дождем, когда по ночам минус - неприятно и больно. Слева дачка моего соседа. Он строит ее уже 6 год и потратил миллионов 10, она еще не накрыта крышей, хотя летом он планировал закрыть тепловой контур. У моего соседа свой бизнес, связанный со строительством, он трудолюбивый, аккуратный и богатый. То есть его компетенции и ресурсы не вызывают сомнений.

Справа моя дачка, внутри нее есть мохнатое кресло, теплые полы, горячая ванна, посудомоечная машина, а в печке горит огонь.  Я построил ее за полгода и 2 миллиона рублей и уже 4 год в ней живу. 

+

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

Другими словами почему Паша Дуров, командой из 30 человек тянет телегу с миллиардом пользователей за него вступается Илон Маск и Президент ОАЭ, а ты своей командой из 30 сеньоров почти закончил за год фичу, по регулировке сыра в приложухе для заказа пиццы.  

Для честности сразу скажу, у меня дом 96 метров, у него больше 350, и я не хочу начинать срач, на тему зачем на даче 4 туалета на трех членов семьи и зачем спальня в 50 метров на 2 этаже. Даже если выкинуть это то путем простой экстраполяции мы понимаем, что дом в четыре раза больше оказался в 10 раз дороже и в 20 раз дольше по срокам. 

Привет, Хабр!

Сегодня я расскажу о нашем внутреннем пространстве для экспериментов под названием «Гараж». Его главная идея – предоставить сотрудникам комфортную и понятную площадку для проверки гипотез и реализации новых инициатив. Это своеобразный инкубатор, построенный по принципу трайба и полностью интегрированный в структуру компании.

Самая большая проблема - практически никто не готов признать, что ему нужна помощь. Мало кто планирует на перспективу: все начинают суетиться, когда ситуация доходит до кризиса. В этот самый момент меня и зовут. Я помогаю разрешить проблемы на проектах, когда стандартные методы (разговоры с заказчиком, реструктуризация, обсуждение финансов и другие) уже были использованы и не помогли. В новой статье в блоге ЛАНИТ приведу пять приемов, которые я использовал в разное время и с разными командами. 

На самом деле я никогда не жил и даже не посещал Германию, но сам больше 2 лет назад покинул РФ и переехал в страну Канада. Думаю, Вы согласитесь, что Канада и Германия куда ближе к друг другу по «духу», чем любая из них к России. Написать ответ на ответ меня побудила не сама статья, а скорее комментарии людей под. Для себя я заметил тренд в последнее время, что очень много статей в топе Хабра поднимают тему переезда, сравнения уровня жизни, доходов и пр. Вопрос актуальный во все времена, но сейчас в особенности, думаю не стоит тут вдаваться в подробности. В данной статье отвечу, ИСХОДЯ ИСКЛЮЧИТЕЛЬНО ИЗ СОБСТВЕННОГО ОПЫТА, на особенно активно заминусованный комментарий из упомянутой выше статьи.

Привет, Хабр! Меня зовут Станислав Пуртов, я заместитель директора по автоматизации проектного блока в ПИК. 

В этой статье хочу кратко описать наш опыт формирования команды.

За последние 6 лет внедрения BIM в компании мы прошли путь от небольшой группы развития из 7 человек до самостоятельной дирекции численностью до 150 сотрудников. Прошли этапы исследования, робкого внедрения, агрессивного внедрения, внедрения на этапах кратного роста наших проектных институтов. И несколько кризисов!

Материал будет полезен руководителям BIM-направлений и руководителям проектных компаний, принявших непростое решение о переходе на BIM. Всех нюансов в одном рассказе не раскрыть — если после прочтения останутся вопросы, пишите мне или моим коллегам лично, и мы с радостью постараемся вам помочь.

Дисклеймер:

Все варианты, описанные ниже — это не теория из интернета, а наш реальный опыт и последовательно описанные этапы того, как менялась наша команда и наши подходы в зависимости от внешних факторов.

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

В этой статье я собрала самые простые и легкие способы, которые действительно помогают быстро принимать ежедневные решения, экономить время, энергию и нервы, освобождая место для действительно важных действий.

Amazon: обратимые и необратимые решения
Матрица "Ценность vs. Затраты"
Матрица Эйзенхауэра

Добрый день! Меня зовут Игорь. Уже 3 года Я делаю бесплатный сервис для создания ментальных карт MIND IN MAP 🍀. За это время, я создал сотни ментальных карт для работы и учебы. В этой статье я делюсь опытом. Покажу как создавать ментальные карты и расскажу, где это можно делать бесплатно.

Привет, Хабр! Это Глеб Михеев — член ПК, отвечающий за программу широко известной в узких фронтендерских кругах конференции FrontendConf, автор канала «Уставший техдир» и знатный амбассадор работы с джунами. Эту статью я написал по мотивам выпуска моего подкаста Фичи Катятся, где мы с Серёжей Паращенко, автором канала Product Cult, обсудили продуктовый подход. Предлагаю разобраться в теме разочарования. Что именно разочаровывает пользователей, и как это можно изменить. Поехали!

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

Экспертизы в сфере P2P платежек у меня не было, поэтому первоначально пошел гуглить, что это вообще такое, где и как работает. После изучил схему, которую он мне прислал. В голове обрисовалась картинка как это можнно реализовать на практике, я ему рассказал свои мысли, сильные и слабые (на мой взгляд) стороны его идеи. После чего он выдал: а сделать сможешь? Деньги на реализацию есть, ТЗ — напишу, всё как полагается.

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

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

Как использование среды общих данных и инструмента сравнения чертежей может помочь значительно сократить время, затрачиваемое на повторные проверки? На что обратить внимание при выборе систем с таким функционалом? Давайте разбираться.