Jak przygotować się do pierwszej rozmowy o oprogramowaniu bez udostępniania zbyt wielu danych

Przynieś problem jak to się dzisiaj dzieje

Pierwsza rozmowa jest najbardziej przydatna, gdy można opisać ostatni, zwykły przykład pracy. Wyjaśnij, kto zaczyna, przez które narzędzia przechodzi, gdzie ktoś czeka i jak wygląda sukces. Nie potrzebujesz gotowej specyfikacji. Przynieś decyzję biznesową masz nadzieję, że rozmowa pomoże Ci: czy zbudować, co zbadać lub jak uratować istniejący produkt.

Utwórz bezpieczny przykład przed spotkaniem

W fikcyjnym procesie obsługi klienta zastąp nazwy, adresy e-mail i numery zamówień wymyślonymi wartościami. Zachować strukturę wyjaśniającą problem, w tym stany błędów i kroki ręczne. Sprawdź zrzuty ekranu dla kart przeglądarki, powiadomień i szczegółów konta. Zredagowany arkusz kalkulacyjny może nadal zawierać ukryte arkusze lub komentarze; mały cel-zbudowany przykład jest często łatwiejszy do bezpiecznego przeglądu.

Ograniczenia udziału, a nie uprawnienia

Przydatny kontekst obejmuje grupy użytkowników, przybliżone wolumeny transakcji, ważne integracje, terminy i którzy mogą zatwierdzić zakres. Znak szacunkowy jako szacunkowy. Nie wysyłaj haseł, kluczy API, danych karty płatności, pełnych baz danych produkcji lub poufnych dokumentów klienta za pośrednictwem formularza zapytania. Jeżeli późniejsza ocena techniczna wymaga dostępu, należy oddzielnie ustanowić autoryzowany, ograniczony i odwracalny proces dostępu.

Oddzielne zaobserwowane fakty od założeń w krótkim skrócie

Przydatna notatka może się zmieścić na jednej stronie: decyzja, której potrzebujesz, osoby zaangażowane, obecna sekwencja pracy i konsekwencja pozostawienia jej bez zmian. Dodaj jeden zwykły przykład i jeden wyjątek. Jasny opis opóźnionego zatwierdzenia jest bardziej przydatny niż długa lista cech, kiedy nikt jeszcze nie wie, dlaczego zatwierdzenie jest opóźnione.

Załóżmy, że fikcyjny zespół sprzedaży wysyła notowania z arkusza kalkulacyjnego, podczas gdy menedżerowie zatwierdzają zniżki przez e-mail. Zwykły przykład wynika z jednej wyceny do zatwierdzenia. Wyjątek pokazuje skorygowaną cenę wysłaną zanim kierownik zobaczy najnowszą wersję. Określić, która wersja została zatwierdzona, gdzie sprzedawca szukał i co klient otrzymał. Nie zakładaj, że odpowiedzią jest nowy CRM; problem może dotyczyć brakującej zasady rewizji lub niejasnej odpowiedzialności.

Należy oznaczyć każde oświadczenie w sposób obserwowany, oszacowany lub do sprawdzenia. Jeśli ktoś mówi, że korekty zdarzają się często, napisz, kto to zgłosił i jaka próbka mogłaby to wyjaśnić; nie zamieniaj tego w wymyśloną comiesięczną liczbę. Opisz wymagane relacje rekordowe i kanały komunikacyjne za pomocą fikcyjnych identyfikatorów. Możesz wyjaśnić, że dwie wersje należą do jednej wyceny bez dzielenia się prawdziwą tożsamością klienta lub warunkami handlowymi.

Poproś o kolejny krok, który rozwiązuje szczególną niepewność

Porównaj najmniejsze użyteczne opcje podczas rozmowy. Konfigurowanie istniejącego narzędzia może być wystarczające, jeśli może on zachować zatwierdzone wersje. Prototyp może wyjaśnić, w jaki sposób menedżerowie dokonują przeglądu zmian. Może być konieczna kontrola techniczna w celu ustalenia, czy obecny system wystawia wymagane rejestry. Pełna budowa staje się bardziej wiarygodną opcją po zrozumieniu tych niepewności. Należy odnotować, dlaczego wariant był preferowany i jakie dowody mogłyby zmienić ten wybór.

Przypisz właścicielowi każde pytanie bez odpowiedzi. Prowadzenie sprzedaży może określić, które zmiany cen wymagają świeżego zatwierdzenia; upoważniony administrator systemu może sprawdzić dostępny eksport lub dostęp integracji. Dać każdemu dochodzeniu możliwość realizacji, granicę i uzgodniony punkt przeglądu. Ograniczone zadanie odkrywania powinno pozostawić coś, co firma może wykorzystać nawet jeśli rozwój nie następuje, takie jak uzgodniony przepływ pracy, przetestowane ograniczenie lub porównane opcje zakresu.

Wyślij lub uzgodnij pisemne podsumowanie dotyczące pożądanego wyniku, rozważanych opcji, otwartych pytań i następnej decyzji. Zapisać wszelkie proponowane koszty lub terminy w formie wniosku dotyczącego oceny, wraz z jego założeniami; nie jest to potwierdzone oszacowanie dla niewidocznej integracji. Poprawiona niezrozumiana terminologia przed planowaniem zależy od niej. Sama transkrypcja jest kiepskim substytutem uzgodnionego zapisu decyzji: przydatnym rezultatem jest wiedza, kto ustali kolejny fakt i jak wpłynie na projekt.

Pozostawić z konkretną decyzją

Użyj formularza projektu, aby powiedzieć Orvun Labs o wyniku i głównej przeszkody. Rozmowa powinna stworzyć wspólne oświadczenie o problemach i kolejne potrzebne dowody, a nie presję na autoryzację nieokreślonej budowy.

• Który zwykły przykład najlepiej pokazuje problem?
• Co musi ulec poprawie i co może pozostać bez zmian?
• Kto odpowie na pytania i podejmie decyzje?
• Czy wspólne pliki zostały sprawdzone pod kątem tajemnic i danych osobowych?