Dialog techniczny

Jesień 2013 to czas, w którym miałem przyjemność współorganizować dialog techniczny w Ministerstwie Sprawiedliwości.

Czym jest dialog można poczytać przykładowo: http://www.portalzp.pl/aktualnosci/dialog-techniczny-ma-pomoc-w-zredukowaniu-ryzyka-uniewaznienia-postepowania-ze-wzgledu-na-brak-ofert-wykonawcow-1276842/, więc nie będę powtarzał treści.

Moje wrażenia z dialogu. Całe przedsięwzięcie wymaga pewnej ilości czasu, ale daje wymierne korzyści i Organizującemu dialog jak i jego Uczestnikom.

Kilka dobrych rad. Moim zdaniem warto:

  • Przesłać Uczestnikom dialogu listę pytań – łatwo jest wtedy porównać odpowiedzi.
  • Przygotować protokoły ze spotkań oraz regulamin dialogu.
  • Pozwolić uczestnikom zastrzec te fragmenty dialogu i dokumentacji, które są tajemnica ich firm. 
  • Postawić wstępne wymagania dla firmy (wielkość firmy, doświadczenie itd) –> generalnie chodzi o to by na spotkanie przybyły firmy mające doświadczenie.
  • Pozwolić by na cześć pytań uzyskać odpowiedź po spotkaniu.
  • Zarezerwować sobie na spotkanie dużo czasu. Z bardziej wartościowymi firmami rozmawialiśmy nawet 8 godzin.

Uczestnikom dialogu radzę by:

  • Na spotkanie zabierał przede wszystkim inżynierów, wdrożeniowców i osoby merytoryczne. Spotkania z handlowcami są mało sensowne. 
  • Nie bał się dzielić wiedzą. W dialogu chodzi przede wszystkim by urealnić wymagania Zamawiającego.
  • Zastrzegał te informacje, które jego zdaniem chronią jego interesy.
  • Nie bał się zadawać pytań. Jak sama nazwa wskazuje mamy do czynienia z dialogiem a wiec rozmową o tym jak zbudować system w warunkach akceptowalnych dla Zamawiającego jak i dostawcy systemu.

Życzę owocnych dialogów Uśmiech

Podobne wpisy

  • Komunikacja i metodyka w projekcie W ciągu ostatnich kilku lat widzę dość radykalne zmiany w zakresie potrzeb moich klientów. Kilka lat temu królowały szkolenia z UML, BPMN. Dziś nacisk jest położony na proces wytwórczy […]
  • Analiza i projektowanie systemów informatycznych Analiza i projektowanie systemów informatycznych było tematem przewodnim szkolenia, które miałem przyjemność prowadzić 26-27 czerwca dla grupy trzyosobowej. Wśród uczestników jedna osoba […]
  • Artefakt: Wykres Wygaszania Wypuszczenia (Release Burndown Chart) Wykres Wygaszania Wypuszczenia (ang. Release Burndown Chart) śledzi postęp drużyny pod względem planu wypuszczenia. W projekcie  Zespół Scrum śledzi swój postęp pod względem planu […]
  • Jakość dokumentu wymagań Aby dokument wymagań mógł stanowić podstawę dla poszczególnych etapów cyklu życia oprogramowania musi on spełniać podstawowe kryteria jakości. Podstawowe kryteria jakości dla dokumentu […]
  • Struktura zintegrowanej architektury (IAF) Historia Pierwsza wersja opatentowanej struktury zintegrowanej architektury Capgeminiego została opracowana w 1996 roku i opierała się na strukturze Zachman’a (1987) i pomysłach […]
Reklama
MODESTO - licencje Enterprise Architect

Zostaw komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Przewiń do góry