В США создали ноутбук 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С, многие параллели прослеживаются.

Считаю что клиповое мышление - это закономерный результат информационного фастфуда.

Сегодня в рамках новой рубрики #путь_проектного_специалиста своей историей поделилась наша коллега Ольга Романова, автор проектного блога «ПроПроекты», которая прошла путь от консультанта 1С до руководителя проектного офиса в крупнейшей нефтяной компании.

Ольга рассказала с чего начался ее путь в 1С, как важно иметь наставника, поделилась ярким кейсом по внедрению УПП и эталонным списком литературы.

Будем рады вашей обратной связи, ведь формат подкаста мы пробуем впервые.

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

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

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

Запись вебинара «Необходимость методической поддержки проектов внедрения 1С:ERP»

Коллеги, мы разместили запись вебинара о необходимости методического обеспечения IT-проектов на нашем канале в Дзене. На вебинаре Наталья Аникеева обобщает и систематизирует проектный опыт по внедрению проектов автоматизации уровня ERP в части необходимости методической проработки проекта внедрения. В программе вебинара:
— методы выявления необходимости методической поддержки при автоматизации различных функциональных участков бизнеса;
— формирование стоимости и продолжительности методических проектов;
— встраивание методических проектов в дорожную карту;
— выгоды от методической поддержки на этапе внедрения автоматизированной системы и во время ее владения.

Вы всегда сможете обратиться к нему, подлиться с коллегами и клиентами по ссылке:
✅ https://dzen.ru/video/watch/647465876a0c2f23724f7b49?t=19

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

Когда на собеседованиях с проектными специалистами доходит очередь до выяснения причин увольнения с прежних мест работы, в ответе очень часто можно услышать причины не связанные с низкой зарплатой, неинтересным задачам или конфликтами в коллективе. На первое место выходят причины вроде бы разные, но которые можно обобщенно описать как неудовлетворительный контекст. Это когда, например, сотрудник не знает к кому обратиться с вопросом, или он не понимает, кто и чем занимается, когда он не может решить какую-то техническую проблему и пр. И сотрудник объясняет причину своего увольнения тем, что он "задолбался" так работать и не видит перспектив на улучшение. Что ему "проще уволиться, чем работать в этой обстановке, тратя свое время на разгребание всего этого геморроя".

Чтобы немного осветить эту проблему, затронем в этой статье тему командного контекста. Точнее его недостатков.