Проектный центр ГИДИС

Проектный центр ГИДИС Разработка и внедрение информационных систем - очень п

21/01/2021

Интимные отношения заказчик/разработчик

Очень важно не описывать заказчику "молочные реки и кисельные берега".
Сначала поговорите, поймите - что действительно надо для решения тех задач, которые "провисают". А потом осторожно предлагайте решения.
Заказчик - он же как девушка: "что-то сейчас не так, а хочется чтобы было правильно. ....Ты ко мне не приставай. А что ты можешь предложить?...... Нуууу я подумаю. ... Я хочу чтобы ты меня чувствовал. "

Вот такие результаты первой сессии с заказчиком нашел.Все больше и самому нравится именно такой формат. Да и заказчикам ...
07/12/2020

Вот такие результаты первой сессии с заказчиком нашел.
Все больше и самому нравится именно такой формат. Да и заказчикам (самым разным) все больше нравится.

если вы хотите чтобы заказчик начал с вами содержательный диалог, то предложите ему для начала простой и понятный пример...
07/10/2020

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

12/09/2020

Самые главные люди
Кто в любой ситуации самые главные люди? Правильно - те, кто больше всех орет.
Главнее уборщицы в поликлинике нет никого.
Главнее "менеджера-чайки" в проекте просто придумать нельзя.
Так что когда вы чего-то делаете - всегда соразмеряйте свои внутренние моральные резервы с тем, что обязательно появится тот, кто "главный".
И действуйте в соответствии со своими внутренними установками. Либо игнорируйте. Либо сразу "заряжайте с ноги".
Иначе ведь ничего путного не выйдет.
Правда есть еще способ - просто уйти в другое место.
Но уверяю - в другом месте обязательно найдется такой же "главный".
И вы снова встанете перед выбором: "игнорировать" или "с ноги".

01/09/2020

писать заново или дорабатывать?

Вот недавно совсем точно понял почему разработчики очень любят писать все заново, а не редактировать/дорабатывать то, что уже было написано другими. (после того как в очередной раз полезли в код лет 5 назад написанной системы).
Разобраться в том, что написали "кто-то когда-то" - иногда на это может уйти в разы больше времени, чем написать заново. (особенно учитывая всегдашнее отсутствие документации).
С другой стороны - "написание заново" всегда ведет к довольно радикальному изменению системы для пользователя. Что тоже - не есть хорошо.

28/03/2020

Никогда не заказывайте ТЗ аналитику. В смысле - "сделай нам красивое ТЗ, чтобы мы могли передать его разработчикам"
Вы провалите проект (и по деньгам, и по срокам)

Никогда не доверяйте формировать ТЗ разработчикам.
Они все равно его не напишут. С ними нужно строить отношения совсем по другому.

Никогда не принимайте систему без документации.
Если есть возможность - проверьте ее. Хотя бы как-то она должна соответствовать тому что вы получаете.

15/02/2020

Никогда не читайте умных книжек.
Многие знания - многие печали.
Фигачьте по простому.

Если ведь человек прочел что-то, то ведь из него уже это не выбить.

Так что давайте без этих умностей. Просто и понятно. Раз-раз и фигак.

Только вот самому потом стыдно ведь будет.
("ну а чё, я вообще-то не особо стыдливый")

18/01/2020

"Пост-архитектура"

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

27/10/2019

Есть такая профессия - технический писатель.
Он вообще никому не нужен.
Кроме ситуаций "нам быстро необходимо сдать документацию" и "а где можно посмотреть описание системы?".

16/10/2019

Если заставить разработчиков действительно честно отмечать время потраченное на задачи, то наглядно подтвердится теория о том что именно на разработку тратится только 15% рабочего времени.
Остальное уходит на изучение литературы, общение на форумах и "стрелялки".
Вопрос тимлида к разработчику - "ну что? выяснил почему не запускается?" звучит вполне себе обычным.
И на самом деле - это правильно. Лучше два дня подумать - чтобы потом за 10 минут "долететь". )))

14/08/2019

Требование от заказчика по документации.

"Нам нужно от вас частное техническое задание и технический проект. И так чтобы страниц 200 не меньше."
Уточняющий вопрос - "а зачем именно 200?"
"Мы у вас документы будем принимать. Будет создана комиссия. Ей надо показать объем."
"А кто в комиссии?"
"Пока не знаем."
"А они понимают из какой области вообще содержание документов?"
"Это вряд ли"

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

Address

Saint Petersburg

Website

Alerts

Be the first to know and let us send you an email when Проектный центр ГИДИС posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Shortcuts

Share

Category