Jak przekonać członka zespołu do korzystania z frameworka internetowego? [Zamknięte]

Pytanie brzmi następująco: czy jest coś, co mogę powiedzieć / przywołać jako programista, aby przyprowadzić go na moją stronę?

Chciałbym usłyszeć uzasadnione argumenty dla obu stron w tej sprawie, ale głównie sugestie, jak go porozmawiać.

Moja sytuacja jest taka: pracuję nad projektem zespołowym na moim studiach dyplomowych, budując średniej wielkości stronę internetową jako prototyp uniwersytetu. Wszyscy są uznawani za równych w grupie i nie ma jednego wyznaczonego lidera, więc odpowiedzią na ten problem nie może być „pull rank”.

Wszyscy są równi, jednak istnieje ogromna luka w wiedzy między członkami. Członek zespołu, o którym mowa, i ja jesteśmy zdolnymi programistami, chociaż nie ma on doświadczenia w branży. Pozostali trzej członkowie są mniej zdolni, a dwóch całkowicie zrezygnowało z rozwoju. Wszyscy trzej odmówili skomentowania sytuacji z powodu braku wiedzy.

Jako grupa decydujemy, jakie technologie zastosować przy wdrażaniu strony internetowej; konkretnie, czy użyć frameworka PHP (Code Igniter), czy nie.

Opowiadam się za, cytując:

1. Nie wymyślać koła na nowo
2. Dobrze napisana i przetestowana baza kodu do pracy
3. Rozpoczęcie pracy (termin jest bliższy niż chcielibyśmy)
4. Szybkość rozwoju
5. Solidne i łatwe do utrzymania wzorce projektowe oraz dobre praktyki

Opiera się na pracy w taki sposób, w jaki kiedyś:

• Pisanie na zamówienie, jednorazowe funkcje w pliku „biblioteki” tak, jak tego potrzebuje
  • Funkcje dostępu do danych i renderowania tych danych na stronie, pobierania / ustawiania do i z sesji oraz pobierania / wysyłania danych itp
• Posiadanie 1 pliku na stronę (co nie powoduje rozdzielenia obaw między kontrolę, prezentację i dane)

Powody, dla których nie chce używać ram, są w większości oparte na tym, że nie jest w stanie zrozumieć sensu: może już robić te wszystkie rzeczy. Struktura tego nie zmienia, tylko utrudnia, ponieważ musi nauczyć się tej struktury; nie chce używać kodu, którego osobiście nie napisał.

Powiedział także, że „nie ma znaczenia jakość bazy kodu, ponieważ projekt jest jedynie prototypem i nigdy nie będzie utrzymywany”. Dla mnie nie jest to żadna wymówka do napisania niemożliwego do utrzymania kodu.

Rozumiem, dlaczego wysuwa te argumenty, ale mam problem z jego „brakiem troski o łatwość utrzymania” i jego „lekceważeniem dobrego projektu”, a nawet oddzieleniem obaw. Podejrzewam jednak, że nigdy nie badał wzorców projektowych, więc nie wiem, jak skuteczne byłoby wykazanie, dlaczego jego metoda może okazać się niemożliwa do utrzymania.

Chcę zająć się tym projektem, ale nie chcę tego robić bez względu na wszystko, czego nauczyłem się przez lata. Jak powiedziałem wcześniej, nie ma tu możliwości podniesienia rangi, ani inni członkowie zespołu nie są skłonni do wskakiwania. Czy powinienem po prostu się wycofać i zrobić coś po swojemu? Czy jest zbyt uparty i niedoświadczony, by wiedzieć lepiej? A może jestem tu uparty?

TL; DR Niedoświadczony członek zespołu jest uparty, jak mogę go przekonać?

Nie będziesz w stanie namówić go do tego. Nazywa się to efektem Dunninga-Krugera . Jest zbyt ignorantem, aby wiedzieć, czego nie wie, i zbyt boi się stracić to, co uważa za zaletę.

Jeśli nie jesteś w stanie osiągnąć konsensusu, musisz zamiast tego dojść do kompromisu. Może możesz podzielić pracę, aby jego potrzeba uczenia się ram była minimalna. Może masz jakieś „projektowanie”, w którym każdy robi to po swojemu przez kilka tygodni, a następnie zespół głosuje, który z nich jest najlepszy. Być może możesz zaangażować swojego profesora sponsorującego lub kogokolwiek, kto jest klientem w rozwiązywanie remisu.

Jednym argumentem na twoją korzyść jest możliwość ponownego wykorzystania wiedzy. Wszyscy członkowie zespołu, którzy nauczą się dobrze znanego i szeroko stosowanego frameworka (takiego jak CodeIgniter), będą mogli ponownie wykorzystać swoją wiedzę przy następnym projekcie. Podczas gdy wiedza o przypadkowej, zastrzeżonej „bibliotece” nie jest wielokrotnego użytku. Może to dobrze współbrzmieć z innymi członkami zespołu, ponieważ prawdopodobnie wolą oni zdobyć trochę użytecznej wiedzy na temat tego projektu.

Kolejnym argumentem może być konkretny pomiar kosztów prac rozwojowych / utrzymania. Wyobrażam sobie, że programista dobrze zorientowany w CodeIgniter może rozwijać się szybciej niż twój kolega, pisząc wszystkie te zastrzeżone funkcje. Można to wykazać, budując identyczną stronę internetową - ty i CodeIgniter, on na swój sposób - i mierząc czas do ukończenia. Następnie dokonaj zestawu modyfikacji / rozszerzeń stron, ponownie mierząc czas do ukończenia. Oczywiście specyfikacja powinna zostać przygotowana przez osobę niezależną od was obu, aby walczyć na neutralnym gruncie.

Kolejnym - jak wspomniałeś - jest jakość kodu. Gdy strony będą gotowe, uruchom na każdym z nich ten sam zestaw testów akceptacyjnych i porównaj gęstość błędów.

Oczywiście, gdy jesteś pod presją czasu, może nie być możliwości zatrzymania się i wykonania takich pomiarów. Prawdopodobnie chcesz więc szybko rozwiązać ten dylemat. Spróbuj przekonać innych członków zespołu (np. Każąc im przeczytać nadchodzące odpowiedzi na Twój post tutaj :-), aby wywrzeć na niego presję grupową. W końcu, jeśli naprawdę nie da się go przekonać, możesz podzielić projekt na dwie części, jedną dla niego i - najlepiej - dla reszty zespołu, używając CodeIgniter. Skoncentruj się na wykonywaniu własnych zadań najlepiej jak potrafisz i pozwól mu robić, co tylko zechce. Wyniki prawdopodobnie będą mówić same za siebie.

Uważam, że musisz zaangażować pozostałych 3 członków drużyny. Oboje musicie przedstawić im swoje argumenty i wyjaśnić im różne rzeczy, aby zrozumieli. Pod koniec dnia będą musieli również pracować z tą bazą kodu. A jeśli wszyscy są równi, powinni mieć coś do powiedzenia nad tym, z czym chcą pracować.

Myślę, że dobrym podejściem dla każdego z was byłoby przedstawienie korzyści płynących z poszczególnych rozwiązań i pokazanie pozostałym członkom zespołu, dlaczego uważasz, że to najlepsza droga. Następnie pozwól im zdecydować. Jest ich 3, więc będzie remis.

Jedną rzeczą, na którą powinieneś zwrócić uwagę, jest to, że jeśli jest to twój projekt starszy, a pozostali członkowie zespołu nie mają innego doświadczenia, projekt ten musi odzwierciedlać pracę, jaką mogą wykonać dla potencjalnych pracodawców. Jeśli zrobisz to dobrze, może to być dobry punkt do rozmowy w wywiadzie. Wiem, że pytam nowych absolwentów o zarys ich projektu dla seniorów oraz o to, jak został zaprojektowany i opracowany.

Jeśli pójdą z podejściem drugiego faceta, będziesz musiał go wyssać. Ale nie porzucaj nadziei. Wymyśl dobry projekt, aby chaos, który pisze, nie wpłynął na wszystko. Jeśli masz czas, zrób trochę kodu, uporządkuj niektóre z jego rzeczy i pokaż mu, że nie musi za każdym razem wymyślać koła na nowo.

Czuję, że college jest jak piaskownica. Większość rzeczy, które tam robisz, nie są używane podczas wdrażania. Dzięki temu masz dużo więcej swobody w eksperymentowaniu i wydostaniu się ze strefy komfortu. Przeglądaj nowe rzeczy, ponieważ niepowodzenie nie będzie miało zbyt dużego wpływu. Również w twojej sytuacji członkowie twojego zespołu mają tę dodatkową zaletę, że pomagają im osoby z wcześniejszą wiedzą.

Jeśli chodzi o drugiego doświadczonego członka zespołu, nie musiał on przychodzić na studia, jeśli nie chciałby uczyć się niczego nowego. To dobra okazja, aby dowiedzieć się czegoś nowego i dodać to do swojego zestawu narzędzi.

A dla niedoświadczonych członków zespołu ich szanse na zatrudnienie / lepsze zatrudnienie wzrosną wraz z ramami takimi jak CodeIgniter w ich życiorysie (w rzeczywistości wiedza uzasadniająca to w życiorysie).