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

Из рабочих диалогов😊

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

Один из руководителей проектов, про коллегу: Ну вот Антон говорил, что закончил "Прикладную информатику"...

Второй руководитель проекта: Ну вот видишь, поэтому он в свои 25 уже руководитель программы проектов, все-таки образование первично!

Антон (флегматично): Это не из-за диплома, а из-за первого места работы, начинал аниматором на детских праздниках...

@upravlenieproektami

У нашего коллеги Артема Кузнецова вышел доклад на Инфостарте про мониторинг систем в 1С. В своей статье он рассказал о том, как научиться узнавать о проблемах не только от пользователей, но и прогнозировать их заранее.

Давайте поддержим Артема лайками и комментариями
➡️ https://infostart.ru/1c/articles/1865372/

Скоро все будут работать в vr очках и забудут про экраны.

В США создали ноутбук Spacetop со 100-дюймовым экраном, который может поместиться в женскую сумочку. Фишка в том, что огромный дисплей видно только в VR-очках.

Стоит это удовольствие 2к долларов — всего-то.

Коллеги, как часто в своей практике вы работали по договору консорциума?

В новой статье Юлий Минькин подробно разобрал этот вид сотрудничества применительно к IT-проектам:
— Как могут быть распределены права и обязанности участников консорциума в IT-проекте.
— В чем выгода участников консорциума по сравнению с договором подряда.
— Какие существуют недостатки участия в консорциуме.
— Что необходимо предусмотреть при заключении договора консорциума.

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

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

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

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

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

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

Друзья, мы запускаем на канале рубрику #путь_проектного_специалиста , в рамках которой будем делиться карьерными историями наших коллег. Рубрика будет выходить в разных форматах: статьи, видео интервью, подкасты.

📝 Если вы готовы поделиться своими путем в проектной деятельности, напишите в комментарии или в личные сообщения и мы опубликуем вашу историю.

Первая историей в нашей рубрике #путь_проектного_специалиста это история Геннадия Сачкова, руководителя московского офиса Первый Бит.

Геннадий Сачков начал свой путь в компании Первый Бит 20 лет назад с позиции внедренца. За это время он работал во внедрении, реализовал масштабный проект по автоматизации Московского областного БТИ, сформировал сначала группу, а затем — отдел внедрения, и вырос до руководителя офиса.

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

Когда не по Хуану сомбреро или как определиться с проектной технологией

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

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

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

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

Интересно, кто-нибудь еще пользуется этим методом? Будет здорово узнать, работает ли это у других.

Устав команды: назначение и структура документа

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

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

Внедрение 1С глазами аналитика: узкие места при автоматизации системы

Автор: Елена, аналитик 1С

Впервые я увидела 1С в 2002 году и с тех пор не расставалась с системой и развивалась профессионально вместе с ней 😊 За это время с программным продуктом я сталкивалась с разных сторон. Как заказчик, активный пользователь, руководитель отдела внедрения, ведущий инженер-программист, разработчик, системный аналитик, руководитель проектов, фрилансер, тренинг-менеджер, преподаватель, все грани с ходу и не вспомнить. Но находясь в профессии более 20 лет поняла, что меня вдохновляет и как я могу применять свои знания с пользой без потери интереса и выгорания.

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

Как и при внедрении любой другой системы, при проектировании в 1С могут возникнуть различные сложности и трудности. Некоторые из них могут включать в себя:
1️⃣ Сложность формирования требований. Иногда бывает непросто определить, что именно необходимо автоматизировать в системе, какие процессы должны быть учтены и какие функции должны быть реализованы.
2️⃣ Недостаточная подготовка пользователей и сотрудников компании. Участники процесса внедрения могут не иметь достаточного знания и опыта работы с 1С, что может затруднять работу над проектом.
3️⃣ Необходимость интеграции с другими системами. В некоторых случаях 1С может быть не готовой к интеграции с другими системами, поэтому для успешного внедрения необходимо обеспечить ее совместимость с другими инструментами.
4️⃣ Недостаток квалифицированных кадров. Для успешного внедрения 1С необходимо наличие квалифицированных специалистов, владеющих не только знаниями по данной системе, но и понимающих специфику бизнеса компании.
5️⃣ Важно правильно настроить систему и хорошо знать функционал. При настройке 1С важно проработать вопросы: от параметров учета до кропотливого составления матрицы прав доступа пользователей. Так, на моем опыте ошибка архитектора и его нежелание вникнуть в возможности функционала целевой системы, прислушаться к опытным коллегам повлекли за собой серьезное увеличение стоимости проекта и изобретение «неустойчивого велосипеда».

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

Реально ли обеспечить такой подход и учесть все аспекты или это утопия? Коллеги, поделитесь какие сложности вы для себя выделяете и каким аспектам уделяете внимание в первую очередь?

MVP: как получить «минимально жизнеспособный», а не «минимально полезный» продукт https://habr.com/p/736240/

Занятная статья о mvp. Хотя в статье идёт речь не о проектах 1С, многие параллели прослеживаются.