При разработке новой системы следует ли всегда обсуждать схему БД с заинтересованными сторонами?

Question

Я на несколько уровней выше уровня людей, вовлеченных в проект, который я собираюсь описать.

Общее требование к веб-системе управления проблемами. Система является небольшой частью гораздо более крупного проекта.

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

• В холодном фьюжн было разработано новое приложение!?!?
• приложение имеет крайне плохая проверка данных
• страница проверки данных приложения перемещается от формы ввода данных
• страница справки приложения перемещается от формы
• Схема БД не обсуждалась между разработчиком и личным администратором
• схема БД не обсуждалась, потому что она не существует
• есть страница меню - т. Е. Как только вы переходите на страницу, вы должны вернуться в главное меню и затем перейти к следующей странице, которую вы хотите
• ведущий вечера не знает, что такое дбмс ...
• есть технический пм, и она не знает, что такое дбмс ...
• ведущий вечера давно хотел уволить технолога, но техник защищен ...
• ведущий вечера предположил, что требуемая функциональность существует в нескольких проприетарных проектах (некоторые из которых с открытым исходным кодом - bugtracker, bugzilla и т. Д.), Но технические специалисты pm и dev не будут слушать.

У меня есть два вопроса?

У меня

• уволить разработчика?
• уволить технолога и человека, защищающего ее?
• уволить ведущего вечера?
• скачать и настроить для них bugtracker / bugzilla и затем запустить их все?
• скачать и настроить bugtracker / bugzilla для них, а затем пойти выпить пива, чтобы забыть мои печали?

и не является ли это СОП для схемы БД, которая будет обсуждаться и тщательно продумываться в самом начале проекта?

EDIT:

Раньше я работал с широким кругом клиентов с разным уровнем технических знаний (и интеллекта). Я всегда обсуждал схему БД с заинтересованной стороной. Если бы они не знали, что такое схема, я бы научил их. Если бы у них не было оснований для понимания, я все равно обсуждал бы с ними схему - даже если бы они не осознавали, что мы говорим о схеме. В большинстве проектов, в которых я принимал непосредственное участие, данные являются наиболее важной частью системы. Тщательное хеширование модели схемы / предметной области имело решающее значение для хорошего понимания системы и того, что можно сделать и о чем можно сообщить. Я высоко ценю мнения авторов постеров о SO. Интересно отметить, что мой подход не обычный курс.

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

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

Я решил выпить два пива и вернуться к своим обязанностям ...

Answer 1

Хорошо, во-первых, чтобы ответить на ваш вопрос: нет, тысячу раз, нет! Пользователи не являются людьми, с которыми вам следует обсуждать схемы БД; в общем, вы бы тоже обсудили исчисление с коровой. Даже если у них есть техническое образование, как насчет следующего изменения требований; должны ли они участвовать в обновлении схемы?

В более общем смысле это звучит как случай, когда технические лидеры позволяют проблеме выйти из контакта с «клиентами» или заинтересованными сторонами. Если вас просят на самом деле исправить проблему, я бы посоветовал вам создать какой-нибудь прототип GUI, может быть, даже просто раскадровку, и пройти через , что . тогда у вас будет представление о том, как обстоят дела.

Extended : да, было бы нормально обсудить схему БД в рамках проекта. Я бы сказал, что вам нужно серьезно подумать о некоторых важных консультациях с ведущими.

Extended more : Я понимаю вашу точку зрения, но дело в том, что схема базы данных - это деталь реализации. Мы настолько привыкли к базам данных, что позволяем себе не замечать этого, и в итоге получаем приложения, которые, ну, в общем, выглядят как базы данных. Но база данных не то, что обеспечивает ценность для клиента; это может ли клиент делать то, что он хочет. Если вы связываете способы, которыми клиент видит приложение со схемами БД, то вы связываете их с одной реализацией; изменение, такое как денормализация таблицы для создания более эффективной системы, становится тем, что вы должны показать клиенту. Лучше показать им наблюдаемые и сохранить эти детали при себе.

Но я подозреваю, что у нас тоже есть конфликт терминологии. Я бы согласился с вами на «модель предметной области». Если под схемой БД вы имеете в виду только те таблицы и отношения, которые видны в представлении системы пользователем, если хотите, то «варианты использования», тогда мы согласимся.

Answer 2

Данные должны быть обсуждены с заинтересованными сторонами, безусловно, да. БД SCHEMA НЕ следует обсуждать с заинтересованными сторонами, за исключением особых обстоятельств, когда все заинтересованные стороны "разбираются в базах данных".

Так как же вы можете обсуждать ДАННЫЕ без обсуждения схемы БД? Это основное использование, которое я нашел для диаграмм Entity-Relationship (ER) и модели ER в целом. Многие разработчики баз данных склонны рассматривать ER как размытую версию реляционного моделирования данных (RDM). По моему опыту, его можно использовать с большей выгодой, если вы не считаете его разбавленным RDM.

В чем разница между ER и RDM? В RDM для связи многих со многими требуется распределительная коробка посередине. Эта распределительная коробка содержит внешние ключи, которые связывают распределительную коробку с участниками в отношениях «многие ко многим».

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

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

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

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

Заинтересованные стороны, которые понимают данные, как правило, интуитивно понимают эти понятия, хотя термины «сущность», «отношения», «атрибут» и «домен» могут быть им незнакомы. Заинтересованные стороны, которые не понимают предметные данные, требуют особого отношения.

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

С помощью довольно механического процесса можно превратить хорошо построенную диаграмму ER в умеренно хорошо построенную реляционную схему. Более творческий процесс проектирования может привести к «лучшей» схеме, которая логически эквивалентна. Несколько технических заинтересованных сторон должны понимать реляционную схему, а не просто диаграмму ER. Не показывайте реляционную схему людям, которым это не нужно знать.

Answer 3

Ну, во-первых, вы, вероятно, должны очень внимательно изучить отношения между техническим персоналом и ее спонсором. Я удивлен, что вы говорите, что технический защитник защищен, когда позже вы подразумеваете, что можете уволить защитника. Либо она есть, либо она не защищена. Если вы можете запустить защитника, то она НЕ защищена.

Похоже, никто не защищен, и еще хуже - никто не общается. Я бы порекомендовал следующее: созвать совещание с ведущим, техническим специалистом и разработчиком. Собравшись вместе, спросите каждого по очереди: «Не ссылаясь ни на что, кроме ВАШЕЙ работы (т.е. вы не можете обвинять кого-либо еще в течение этого упражнения), скажите мне через 5 минут или меньше, почему я НЕ должен уволить вас сегодня».

Я понимаю, что это очень важный совет, но вы описали УЖАСНОЕ решение классической проблемы. Каждый аспект этого проекта и полученный «код» звучит как катастрофа. Вы, вероятно, должны были лучше контролировать этот беспорядок, но вы этого не сделали (по какой-либо причине). Я понимаю, что вы должны ожидать, что наемные специалисты на уровне PM будут лучше, чем это.

Отсюда моя рекомендация для серьезной встряски команды. Как только вы положите страх безработицы за стол (и я скажу им, что вы записываете неспособность общаться для каждого из них), ПОТРЕБИТЕ их опубликовать планы немедленного улучшения коммуникации, плюс подробные сроки для исправления беспорядка с помощью конец недели.

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

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

Приветствия

-R

Answer 4

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

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

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

Поэтому, если ваше описание и мои удивительные экстрасенсорные способности дали мне ясную и точную картину:

Защитите ведущий вечера от возмездия и скажите ему, чтобы он отбросил всю грязь и внедрил готовое решение. (Если он не может сам выбрать надежного, он не должен быть ведущим вечера.)

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

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

Answer 5

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

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

Answer 6

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

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

Есть несколько возможных решений:

• Получить лучший кодер. Ему не понравится работать со всем плохим кодом, но, надеюсь, он будет пробираться через него до тех пор, пока это не будет сделано. Надеюсь, вы готовы заплатить ему хорошие деньги.
• Держи кодера и заставь его все исправить. Наймите нового премьер-министра, который сможет управлять им лучше. Этот кодер лучше знает свой код, и ему может потребоваться меньше времени, чтобы просто улучшить его. В конечном счете, вам лучше не держать плохого кодера в платежной ведомости, поэтому потеряйте его, когда закончите.
• Смиритесь с этим, купите пиво для всех участников и начните заново с открытым исходным кодом. Вам, вероятно, все еще понадобится технический менеджер для управления программным обеспечением. Вы также должны будете забыть о том, чтобы делать что-то обычное в этот момент. Возможно, подрядчик мог бы справиться с этим.

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

Answer 7

Ничего себе. Я чувствую твою боль.

Мне кажется, что первым источником вашей проблемы является "защищенный" techPM. Почему она защищена и кем? Однажды я был в проекте, где секретарь генерального директора стал сначала бизнес-аналитиком, а затем (после того, как он ушел) руководителем проекта, потому что у них был роман. Она не знала, на каком языке мы программируем, и считала, что требования - пустая трата времени. Поскольку она была защищена кем-то настолько высоким, насколько это возможно в организации, единственным реальным решением было искать работу в другом месте.

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

Ведущий PM может или не может быть спасен в зависимости от того, кто был защитником. Он мог оказаться между молотом и наковальней, где он знал, что делать, но из-за характера отношений между техническим персоналом и ее защитником не мог оказать никакого влияния на нее и людей, которые отчитывались перед ней. Однажды я находился в таком положении, когда у двух моих боссов были отношения с одним из моих подчиненных, и это создавало все виды организационного хаоса (именно поэтому должен быть уволен и защитник, и технический директор). Дайте ему выгоду от сомнений и обсудите с ним, как он поступил бы по-другому, если бы техник и ее защитник были в стороне. Если вам нравится то, что вы слышите, вы можете оставить его, но организационно вам нужно будет вмешаться и убедиться, что ясно, что этот человек отвечает, и никто не сможет его игнорировать. После того, как лидерство потеряло авторитет, он может получить его только при сильной поддержке со стороны руководства.

Я бы также сел с ведущим и разработчиком и объяснил, что именно является неприемлемым в проекте в его нынешнем виде. Если разработчик чувствует себя неспособным принять руководство от лидера (при условии, что вы решите оставить его) или не в состоянии приспособиться к новому способу ведения бизнеса или не может понять, почему код в его нынешнем виде неприемлем, сократите свои потери и избавьтесь от его тоже. Новый человек, вероятно, будет лучше работать для лидера, если он все равно может быть спасен, потому что у него не будет истории игнорировать его.

Answer 8

Прежде всего, я согласен с Чарли Мартином насчет схемы БД.

Второй,

Похоже, что разработчик проекта очень зеленый - это его / ее первая работа по программированию? Если это так, я бы уволил разработчика, только если их резюме говорит что-то еще.

Я не знаю, как ожидается, что ведущий / технический pms будет участвовать в проекте, но похоже, что ответственность лежит на dev> tech pm> lead pm. Если это так, то технический менеджер полностью отбросил мяч. Возможно, вы захотите выяснить, почему мяч был уронен, и уволить / удержать ее на этом основании, но такая неудачная работа - это время выговора, где я работаю.

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

Удачи! Ура!

Answer 9

Ух, звучит как катастрофа. Позвольте мне обратиться к вашим пунктам в приблизительном порядке:

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

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

3. Веб-диалоги не могут быть "модальными" в том смысле, в каком вы думаете. Тем не менее, это достаточно легко, чтобы открыть дополнительное окно. Справка на странице должна почти всегда использовать всплывающее окно такого рода.

4. Проверка данных НИКОГДА не должна уходить со страницы, где вводятся данные - это ужасный дизайн пользовательского интерфейса.

5. Схема БД является наименьшей из ваших проблем. Если разработчик отвечает за предоставление функциональных возможностей и явно компетентен в проектировании схемы данных, я не думаю, что важно обсуждать нюансы схемы с ведущим руководителем проекта. Это должно обсуждаться между различными заинтересованными сторонами на уровне кода, и оно должно быть способным справляться с требованиями работы. Однако с точки зрения премьер-министра важна не столько схема, сколько эксплуатационные аспекты. Конечно, если вы не верите в способность разработчика создать хорошую схему БД, все ставки отменены.

6. Если вы серьезно не знаете, что такое дбм, у вас может быть серьезная проблема. У тебя есть стандарт? Если все остальные участники расширенного проекта используют MS SQL Server и этот парень выбрал Oracle, как вы переносите опыт и персонал в этот проект или из него? Это признак неконтролируемой организации.

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

8. Что касается увольнения дэва ... возможно ли помочь ему, спонсировав какое-то дополнительное обучение? Если этот человек в противном случае является хорошим сотрудником и хорошо знает ваш бизнес, я бы очень не хотел увольнять их, когда все, что нужно, - это толчок в правильном направлении.

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

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

11. Если багтрекер и т. Д. Действительно работают, то имеет смысл пойти по этому пути. Тем не менее, вы, возможно, захотите быть более осторожными в увольнении людей.

Answer 10

ведущий вечера предположил, что точное требуемая функциональность существует в несколько частных проектов (несколько из которых с открытым исходным кодом - bugtracker, bugzilla и т. д.), но технический пм и Дев не слушал.

Если это правда, скажите ведущему вечера быть более напористым; затем скажите ему / ей установить bugzilla и покончить с этим. Если технический менеджер и разработчик не слушали из-за упрямства, им нужно немного поболтать ...

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

Что касается обсуждения схемы БД со всеми, я бы сказал, нет. Каждый, кто может внести положительный вклад, должен быть вовлечен после того, как требования к заявке будут собраны.