සෑම දෝෂ වාර්තාවකටම “දොස් පැවරිය යුතු” ක්ෂේත්‍රයක් එක් කිරීමට මගේ ලොක්කා තීරණය කළේය. එය නරක අදහසක් බව මම ඔහුට ඒත්තු ගන්වන්නේ කෙසේද?

නවතම "ඩබ්ලිව්ටීඑෆ්" පියවරක් තුළ, අපගේ ලොක්කා තීරණය කළේ අපගේ දෝෂ ලුහුබැඳීමේ අච්චුවට "දොස් පැවරිය යුතු" ක්ෂේත්‍රයක් එකතු කිරීමෙන් වගවීම වැඩි වනු ඇති බවයි (අපට දැනටමත් විශේෂාංග / කථා වලට දෝෂ ගැටගැසීමේ ක්‍රමයක් තිබුණද). මෙය චිත්ත ධෛර්යය අඩු කරයි, ඇඟිල්ල දිගු කිරීම වැඩි කරයි සහ දෝෂය ලෙස වාර්තා වී ඇති / වැරදියට වටහාගෙන ඇති අංගයන් නොසලකා හරිනු ඇතැයි යන මගේ තර්ක අසන්නට නොලැබුණි.

මට භාවිතා කළ හැකි මෙම භාවිතයට එරෙහිව තවත් ප්‍රබල තර්ක මොනවාද? මෙම මාතෘකාව පිළිබඳ මට ලිවීම කණ්ඩායමක් හා ලොක්කා සමඟ බෙදා ගත හැකිද?

වෘත්තිකයන් විසින් භාවිතා කරන Root Cause ක්ෂේත්‍රය සඳහා මෙය ආධුනික නමක් පමණක් බව ඔවුන්ට කියන්න (නිකුත් කිරීමේ ලුහුබැඳීම් සඳහා විශේෂිත ක්ෂේත්‍රයක් නොමැති විට, ඒ සඳහා අදහස් දැක්විය හැකිය).

වගේ දෙයක් සඳහා වෙබ් අඩවි පරීක්ෂා කිරීම මෘදුකාංග දෝෂ මූල හේතුව විශ්ලේෂණය මෙම තර්ක යුක්ති සහගත කිරීමට සම්පත් ඕනෑ තරම් ඇත ^{1 , 2 , 3 , 4 , ...} .

... දෝෂයක් සඳහා මූලික හේතුව සෑම විටම තනි සංවර්ධකයෙකු නොවේ (මෙම ක්ෂේත්‍රයේ ප්‍රධාන කරුණ මෙයයි) ...

“මුලික හේතුව” වෘත්තීය වන අතර “දොස් පැවරිය යුතු පුද්ගලයා” ආධුනිකය. පුද්ගලික වගවීම විශිෂ්ටයි, නමුත් එය හුදෙක් dev කණ්ඩායමට පිටතින් තැබූ අවස්ථා තිබේ.

වන විට එහි ඔබගේ ලොක්කා කියන්න වන වරද සඳහා තනි සංවර්ධක, මූල හේතුව ක්ෂේත්රයේ අනිවාර්යයෙන්ම (එම ආවරණය වනු ඇත "1234 සිදු දී බොබ් විසින් කරන ලද වරද ගණයට අයත්, ජිම් විසින්, සමාලෝචනය 567 ගැනීමත්," ). පදය භාවිතා කිරීමේ ලක්ෂ්යයක් මූල හේතුව , ඒ වගේ අවස්ථා ආවරණය කිරීමට ඔස්සේ මෙම dev කණ්ඩායම හි විෂය පථය පිටතට යන්න බව නඩු.

^{නිදසුනක් ලෙස, දෝෂය සිදුවී ඇත්තේ වැරදි දෘඩාංග නිසා නම් (එය මිලදී ගත් සහ පරීක්ෂා කළ කණ්ඩායමට පිටින් කෙනෙකු යැයි දොස් පැවරිය හැකි පුද්ගලයා සමඟ), මූල හේතු ක්ෂේත්‍රය එය ආවරණය කිරීමට ඉඩ දෙන අතර “තනි සංවර්ධකයාට දොස් පැවරීම” සරලවම කැඩී යයි මෙම ප්රශ්නය ෙසොයා ගැනීෙම් ප්රවාහය.}

^{Dev කණ්ඩායමට පිටින් යමෙකු විසින් ඇති කරන ලද වෙනත් දෝෂ සඳහාද මෙය අදාළ වේ - පරීක්ෂක දෝෂ, අවශ්‍යතා වෙනස් කිරීම සහ කළමනාකරණ තීරණ. ආපදා ප්‍රතිසාධන දෘඩාංග සඳහා ආයෝජනය කිරීම කළමනාකරණය විසින් තීරණය කළහොත්, දත්ත සමුදායේ විදුලිය ඇනහිටීමක් සඳහා “තනි සංවර්ධකයෙකුට දොස් පැවරීම” තේරුමක් නැති දෙයක් යැයි පවසන්න.}

එවැනි ප්‍රතිපත්තියක් සඳහා තවත් ප්‍රති result ලයක් වනුයේ මිනිසුන් “දොස් පැවරිය යුතු පුද්ගලයා” යැයි සිතන්නේ නම් ඔවුන් දෝෂ වාර්තා නොකිරීමයි, එබැවින් එය කණ්ඩායම විසින් වාර්තා කරන ලද දෝෂ ගණන අඩු කරනු ඇත.

මම එයට එරෙහිව භාවිතා කරන ප්‍රධාන තර්කය නම් ඔහු විසඳීමට උත්සාහ කරන්නේ කුමන ප්‍රශ්නයද යන්නයි. එකම ගැටළුව විසඳීමට වඩා හොඳ ක්‍රම තිබේ.

එක් දෙයක් නම්, දොස් පැවරිය හැක්කේ එක් පුද්ගලයෙකුට පමණක්ද? තිබේ නම්, ඔබ කරන්නේ වෙනත් වැරැද්දකි. හොඳ ක්‍රියාවලියක් නිෂ්පාදනයට යාමට පෙර විශ්ලේෂකයෙකු, ක්‍රමලේඛකයෙකු, සමාලෝචකයෙකු සහ පරීක්ෂකයෙකු හරහා වැඩ කොටසක් ලබා ගනී. ඔබ මෙම සියලු අදියරයන් නොකරන්නේ නම්, සමහර විට එය ඔබගේ ලොක්කා විසඳීමට උත්සාහ කරන ගැටලුවට විසඳුම විය හැකිය. ඔබ එසේ නම් වරද පැටවිය යුත්තේ කාටද? එය ඔවුන්ගෙන් කිසිවෙකු නොවිය හැකිය, එය දොස් පැවරිය යුතු උරුම කේතය විය හැකිය.

මිනිසුන් පිටුපසට දෂ්ට කිරීම සහ ඇඟිලි තුඩු දීම හොඳ නැත, කළු සලකුණක් වළක්වා ගැනීමට උත්සාහ කිරීම, එය සැකසූ වහාම ඉවතට නොයනු ඇත. එය කිසිවක් විසඳන්නේ නැත. ඉතා සුළු පිරිසක් ද්වේෂ සහගත ලෙස නොසැලකිලිමත් වේ. ඔබ නිසි ලෙස නැවත සලකා බැලීමක් කළ යුතුය , වැරැද්ද කුමක්ද සහ එය නැවත වැරදි නොවන බවට වග බලා ගැනීමට ඔබට කළ හැකි දේ බලන්න.

එයින් ඔබට පැහැදිලිව පෙනෙනුයේ එක් පුද්ගලයෙකු නිතිපතා වැරැද්දක් කර ඇති අතර එය සමඟ කටයුතු කිරීමට වෙනස් ගැටළුවක් විය හැකි බවයි.

වගවීම නිර්මාණය කිරීමේදී කළමනාකරුවෙකු නැවැත්වීමේ උපක්‍රමය නම් එය නොමිලයේ පිරිනැමීමයි , නමුත් එය ඔබට සැබවින්ම අර්ථවත් වන අයුරින්.

එම ක්ෂේත්‍රය සමඟ අවම වශයෙන් ගැටළු තුනක් වත් තිබේ.

පළමුවැන්න නම් මිනිසුන්ට දොස් පැවරීම චිත්ත ධෛර්යයට යහපත් නොවන බවයි. හරි. නමුත් සමහර විට ඔහු චිත්ත ධෛර්යය ගැන තැකීමක් නොකරන අතර නරක සංවර්ධකයින්ට වෙඩි තැබීමට අවශ්‍ය විය හැකිය. විරුද්ධව තර්ක කිරීමට අපහසුය.

දෙවැන්න නම්, එම ක්ෂේත්‍රය නිවැරදිව ලබා ගැනීම දුෂ්කර වන අතර විශාල කාලයක් ගිලෙනු ඇත. නරක කේතය ලිව්වේ කවුදැයි සොයා ගැනීමට වඩා එය සංකීර්ණ ය. හඳුනා ගැනීමට අපහසු ඕනෑම තොරතුරක් වැලි මලු / වංචා කළ හැකිය. නමුත් සමහර විට ඔහු එම පිරිවැය ගෙවා තොරතුරු විගණනය කිරීමට සූදානම්. හොඳයි.

වඩාත් මූලික කාරණය වන්නේ මෙම ක්ෂේත්‍රය ඉදිරියට ගෙන යාමට හොඳ මෙට්‍රික් එකක් නොවීමයි. කාගේ කේතය වඩාත්ම අඩුපාඩුකම් ඇති කරයිද යන්න ඔහුට හොඳ ශ්‍රේණියක් ඇත. නමුත් එම ලැයිස්තුවේ ඉහළින්ම සිටින්නේ කවුදැයි අනුමාන කරන්න? බොහෝ විට සමාගම් නිර්මාතෘ, හෝ ඉතා අඩු අඩුපාඩු අනුපාතයක් ඇති නමුත් එතරම් tive ලදායී ඉහළ පෙළේ සංවර්ධකයෙකු ඔහු කේතයේ අසමාන කොටසක් ලියයි. ඒ නිසා ඔහු එක්කෝ ඔහුගේ හොඳම සංවර්ධකයාට වෙඩි තැබීම අවසන් කරයි, නැතහොත් ඔහු තව දුරටත් ඔහුගේ හොඳම සංවර්ධකයා නොවන තරමට වේගය අඩු කරයි. මසකට කේත රේඛාවක් ලියන අය - ඊට වඩා අදහස් දැක්වීම - ඔහුගේ අඩුපාඩු සංඛ්‍යා සඳහා ත්‍යාග ලැබෙනු ඇත.

තවත් මෘදුකාංග මෙට්‍රික් අසමත් වීමකි.

ක්ෂේත්‍ර දෝෂයක් සඳහා මූලික හේතුව කිසි විටෙකත් තනි පුද්ගලයෙක් නොවේ. පරිපූර්ණ හෘදසාක්ෂියක් ඇති අය වැරදි සිදු කරනු ඇති අතර, ඔවුන් වැරදිසහගත යැයි අපේක්ෂා කරන ක්‍රියාවලියක් අසාධාරණ ය. ඔබ යෙදවීමට පෙර නිෂ්පාදන පද්ධතිවල වෙනස්කම් සත්‍යාපනය නොකරන්නේ නම්, අතින් හෝ ස්වයංක්‍රීය පරීක්ෂාවකින් නම්, දෝෂ නොවැළැක්විය හැකිය.

වැරදි:

ආදානය පරීක්ෂා කිරීමට බොබ්ට අමතක වූ අතර වැඩසටහන ශුන්‍යයෙන් බෙදීම බිඳ වැටුණි.

දකුණ:

යෙදවීමට පෙර ශුන්‍ය දෝෂයකින් බෙදීමට අවදානමක් ඇති කේතය අනාවරණය නොවීය. අවලංගු ආදානය නිසි ලෙස හැසිරවීම තහවුරු කිරීම සඳහා නව පරීක්ෂණ අවස්ථා එකතු කර ඇත. කේතය නිවැරදි කරන ලද අතර නව පරීක්ෂණ අවස්ථා සියල්ලම සම්මත වෙමින් පවතී.

"දොස් පැවරිය යුතු පුද්ගලයා" ලෙස "ප්‍රශංසා කිරීමට පුද්ගලයා" ලෙස වෙනස් කරන්න

දෝෂ නිවැරදි කිරීමට ප්‍රධාන පුද්ගලයා එහි නම ලබා ගනී.

සරල පිළිතුර.

"දොස් පැවරීම" ක්ෂේත්‍රය පලිගැනීම සහ ඇඟිලි තුඩු දීම හැර වෙන කිසිවක් සඳහා භාවිතා නොකරනු ඇත, චිත්ත ධෛර්යය බිඳ වැටෙනු ඇත, කණ්ඩායම් විශ්වාසය විනාශ වනු ඇති අතර එය නිවැරදි කිරීම වෙනුවට යමක් ඔවුන්ගේ වරදක් නොවන බව ඔප්පු කිරීමට ක්‍රම සොයා ගැනීමට සෑම කෙනෙකුම උත්සාහ කරනු ඇත. දෝෂ වාර්තා කිරීම වෙනුවට නිශ්ශබ්දව සිටීමට මිනිසුන් වැඩි නැඹුරුවක් දක්වනු ඇත, මන්ද සගයකු කරදරයට පත්වීමට ඔවුන්ට අවශ්‍ය නැති බැවිනි. එය සම්පූර්ණයෙන්ම counter ලදායී වේ.

වැදගත්ම දේ, අවංක වැරැද්දක් කිරීම සඳහා යමෙකුට ගොදුරු වීම හෝ ගැටලුව හැකි ඉක්මනින් විසඳීම?

ඔබේ ලොක්කා සිතන්නේ දෝෂ යනු අලසකමේ හෝ අලසකමේ ලකුණක් බවයි. ඔවුන් එසේ නොවේ. ඒවා ජීවිතයේ සත්‍යයකි. වසරක් තුළ මයික්‍රොසොෆ්ට් පැච් කීයක් තල්ලු කරයිද?

ඔබ සුළු සිවිල් අකීකරුකමකට සූදානම් නම්, එක් එක් දෝෂය සඳහා එම ක්ෂේත්‍රයේ සිටින සියලුම සංවර්ධකයින්ගේ ලැයිස්තුවක් තැබීමට කණ්ඩායම එකඟ වන්න. එය නොගැලපේ නම්, "මම ස්පාටකස්!" වෙනුවට. කාරණය නම්, ඇත්ත වශයෙන්ම, ඔබ සියලු දෝෂ සඳහා වගකිව යුතු අතර ඕනෑම දෝෂයක් නිර්මාණය කළ පුද්ගලයා පෙන්වා දීමට ඔබ සතුටු වන්නේ නැත.

තවත් විකල්පයක්: සෙල්ලම් කරන්න. විශේෂයෙන් කිසිවක් නොකරන්න - හොඳ වැඩක් කර මාස කිහිපයක් ඔබට හැකි තරම් නිවැරදිව ක්ෂේත්‍රය පුරවන්න. එක් එක් දෝෂයට දොස් පැවරීම කණ්ඩායමේ සිටින සියල්ලන්ම අසතුටට හා අපහසුතාවයට පත් කරන බව ලොක්කාට පැහැදිලි කරන්න. නිර්මාණය කරන ලද දෝෂ සහ වෙනත් ඕනෑම දෙයක් (කුසලතා, උත්සාහය, සිහිබුද්ධිය) අතර එතරම් සහසම්බන්ධයක් නොමැති බව ඔබ සැමට හැඟෙන බව ඔහුට කියන්න. (ඇත්ත වශයෙන්ම සහසම්බන්ධයක් නොමැති බව පෙන්වන සංඛ්‍යා කිහිපයක් ධාවනය කිරීමට ඔබට හැකි නම් එය උපකාරී වේ.)

ගාන්ධි සිවිල් අකීකරුකම: සෑම ක්ෂේත්‍රයකම ඔබේ නම තබන්න (වෙනත් සංවර්ධකයින් නැගී සිට ඔවුන්ගේ දෝෂ සඳහා ඔවුන්ගේ නම තැබුවේ නැත්නම්), සහ එය ඔබගේ හෝ වේවා සෑම දෝෂයකටම දොස් පවරන්න. මෙයට වඩා වැඩකට නැති කෙනෙකුට දොස් පැවරීමේ අදහස හෝ එම ක්ෂේත්‍රය කිසිවක් ඉදිරිපත් නොකරයි. සෑම ක්ෂේත්‍රයකම ඔබේ නම ඇත්තේ මන්දැයි ඔබේ ලොක්කා ඇසුවොත් ඔබට පැහැදිලි කළ හැකිය “මන්ද සංවර්ධනය යනු දොස් පවරන ක්‍රීඩාවක් යැයි මම නොසිතමි, ඔබට ඇත්ත වශයෙන්ම මිනිසුන්ට දොස් පැවරීමට හා කුරුසියේ ඇණ ගසන්නට අවශ්‍ය නම්, සෑම දෙයකටම මාව කුරුසියේ ඇණ ගසා මගේ කණ්ඩායමට සාමකාමීව වැඩ කිරීමට ඉඩ දෙන්න . "

මා වරක් ලොක්කාට මෙයට සමාන පද්ධතියක් ක්‍රියාත්මක කළ අතර එය ක්‍රමලේඛන නොතිබුණද (එය දිනපතා පුවත්පතක මුද්‍රණ සැලසුම විය) සංකල්පය සහ සුදුසු ප්‍රතිචාරය සමාන වේ.

ඇය කළේ අපගේ ලේඛන කටයුතු සඳහා 'දොස් පැවරිය යුතු' ක්ෂේත්‍රයක් එකතු කරනවා වෙනුවට ඇය එක් එක් නිර්මාණකරුවන්ට වර්ණවත් ස්ටිකර් කට්ටලයක් ලබා දීමයි. සෑම නිර්මාණකරුවෙකුටම වෙනස් පාට ස්ටිකර් එකක් ලැබී ඇති අතර, ඕනෑම සැලසුමක් මත වැඩ කරන හෝ ස්පර්ශ කරන ලද ස්ටිකර් එම නිර්මාණයේ කඩදාසි වැඩවලට එකතු කළ යුතු බවට උපදෙස් දෙන ලදී.

"ස්ටිකර් මුලපිරීම" සඳහා ලොක්කාගේ ප්‍රකාශිත ඉලක්කය වූයේ අපගේ දෙපාර්තමේන්තුවේ සියලු දෝෂවල මූලාශ්‍රය තහවුරු කිරීමයි (ලේඛන කටයුතු වල වැරදි, වැරදි ලිපිගොනු, නරක පිටපත, අත්‍යවශ්‍යයෙන්ම මුද්‍රණයට සමාන දෝෂ)

අප කළ දෙය අනෙක් නිර්මාණකරුවන්ට අපගේ ස්ටිකර් වලින් හතරෙන් එකක් ලබා දී ඇති අතර එමඟින් අප සෑම කෙනෙකුටම සියලු වර්ණ ලබා දී ඇති අතර සෑම මෝස්තරයක් සඳහාම අපගේ වර්ණය පමණක් නොව නිර්මාණකරුවන්ගේ වර්ණ හතරම තැබුවෙමු.

ඔබගේ නම [දොස් පැවරීමේ කොටුවෙහි පමණක් ලියන්න එපා- කණ්ඩායමේ / ව්‍යාපෘතියේ සිටින සෑම කෙනෙකුගේම නම සඳහන් කරන්න, සහ මුළු කණ්ඩායමම එසේ කරන බවට වග බලා ගන්න.

අපි ඇයගේ ඕවල්ලියානු බැල්ලියට එරෙහිව එකට වැඩ කළ අතර එහි ප්‍රති we ලයක් වශයෙන් අපි එකිනෙකාගේ වැරදි අල්ලාගෙන එකිනෙකා සමඟ ඒ ගැන කතා කළෙමු. අවසානයේදී දෝෂ සැලකිය යුතු ලෙස අඩු විය. ඇය ෂාට් මැනේජර්වරියක වූ අතර, ඇයගේ මුලපිරීම අපව එක්සත් කර produc ලදායිතාව ඉහළ නැංවූ බව වටහා ගැනීම වෙනුවට ඇය සියලු දේ ලබාගෙන ස්ටිකර් ක්‍රමය විසුරුවා හැර එය අසාර්ථක යැයි ප්‍රකාශ කර අප සියල්ලන්ටම නිල වශයෙන් තරවටු කළාය.

එය ඔහුගේ වඩාත්ම සාර්‍ථක ක්‍රමලේඛකයාට ද ishing ුවම් කරනු ඇත. අවාසිය නම්, බොහෝ ව්‍යාපෘතිවල වැඩ කළ හොඳම සේවකයින් එක් අයෙකු හෝ දෙදෙනෙකු විය හැකිය. ඔබ පුද්ගලයන් 10 දෙනෙකුගෙන් යුත් දෙපාර්තමේන්තුවක් තුළ, එක් කේතයක් නිමැවුම් උල්පතක් වන අතර ඔහු අතුරු මුහුණතේ කේතයෙන් 60% ක් ලියා තිබේ නම්, දෝෂ වලින් 60% ක් ඔහුගේ කේතයේ ඇත.

මෙම ක්‍රමය මඟින් වැඩිපුරම කේත ලියන පුද්ගලයා නරකම ක්‍රමලේඛකයා ලෙස පෙනෙනු ඇති බවත්, අවම කේතය ලියන පුද්ගලයා හොඳම ක්‍රමලේඛකයා බවත් පැහැදිලි කරන්න.

ස්කොට් ඇඩම්ස් ඩිල්බට්හි පොයින්ටි හෙයාර් ලොක්කාගේ දෝෂය පිළිබඳ අසාර්ථක ප්‍ර wisdom ාව පෙන්වා දුන් විට මෙය බොහෝ සෙයින් සමාන ය. වොලී නිවේදනය කළේ තමා ගොස් ඔහුට නව මිනි වෑන් රථයක් ලියන බවයි.

නිල ඩිල්බට් විකට තීරු ලේඛනාගාරයෙන් 11/13/1995 සඳහා ඩිල්බට් විකට පටිය.

ස්නෝ ස්කීං ක්‍රීඩාවේ යෙදෙන විට මට වැටහී ගියේ 'වැටීම' හොඳ ස්කී ක්‍රීඩකයෙකුගේ ලකුණක් නොවන බවත්, නමුත් බොහෝ විට කිසිවක් උත්සාහ නොකරන (හෝ කිසිසේත් ස්කීං නොකරන) ලකුණක් බවත් ය.

දුර්වල ක්‍රමලේඛනය සහ දුර්වල සැලසුම් මඟින් කේත මඟින් දෝෂ හඳුන්වා දිය හැකිය; නමුත්, ඒවා බොහෝ දුෂ්කර කේත ලිවීමේ ප්‍රති ence ලයක් ලෙසද පැමිණිය හැකිය. වැඩිපුරම දෝෂ නිපදවන පුද්ගලයින් ඩිංග් කිරීම දුප්පත් සංවර්ධකයින්ට ඉහළ tive ලදායී අය මෙන් විය හැකිය.

ඔබේ ලොක්කා අඩුපාඩු ගණන ගැන කලකිරීමට පත්විය හැකි බව පෙනේ. ඔබේ කණ්ඩායමේ පුද්ගලයින් ගුණාත්මකභාවය කෙරෙහි දැඩි ඇල්මක් දක්වනවාද? 'කවුද' යන ක්ෂේත්‍රයට වඩා 'කුමක්' ක්ෂේත්‍රයක් නිර්මාණය කිරීම වඩා .ලදායී විය හැකිය. උදා: අවශ්‍යතා වෙනස් කිරීම, සැලසුම් කිරීමේ දෝෂය, ක්‍රියාත්මක කිරීමේ දෝෂය යනාදිය. නිෂ්පාදනයේ ගුණාත්මකභාවය වැඩි දියුණු කිරීම සඳහා කණ්ඩායමක් අතුරු කණ්ඩායමක් නොමැති නම් මෙය පවා අසාර්ථක වනු ඇත.

සමහර විට ඔබ එය "දෝෂය නිවැරදි කිරීමට සුදුසුම ස්ථානයේ සිටින්නේ කවුද?" මගේ කොටසකටත් දැනෙනවා, ඔබ එය කැඩුවා, ඔබ එය නිවැරදි කරන්න. යම් වගවීමක් තිබිය යුතුය.

යම් ආකාරයක ලකුණු තබා ගැනීමට මම එකඟ නොවෙමි. සමහර අය කේතයේ වඩාත් සංකීර්ණ කොටස් මත වැඩ කරන නිසා තවත් දෝෂ නිර්මාණය කරයි. කේත රේඛා ප්‍රයෝජනවත් මෙට්‍රික් එකක් නොවේ නම්, කේත රේඛාවකට දෝෂ වඩාත් හොඳ යැයි මට සැකයි. කේතය කිසි විටෙකත් පරීක්ෂා නොකරනු ඇත.

යම් අවස්ථාවක දී කළමනාකරුවෙකු තම රාජකාරිය කරන්නේ කවුරුන්ද සහ කවුරුන්ද යන්න මෙන්ම කණ්ඩායමේ අනෙක් අය කරන නිසා එය වඩා හොඳින් කරන්නේ කවුරුන්ද යන්න දැන සිටිය යුතුය.

ඔබේ ඇත්ත ප්‍රශ්නය වූයේ ඔබ සමාගමෙන් ඉවත් වීමට පෙර සංස්කෘතිය වෙනස් කරන්නේ කෙසේද යන්නයි, ඔබේ ලොක්කාට ඒත්තු ගැන්වීමෙන් දෝෂ වාර්තා සඳහා ක්ෂේත්‍රයට දොස් පැවරීම නරක අදහසක් බව. නමුත් ඇත්ත වශයෙන්ම සංස්කෘතිය වෙනස් කිරීම ඔහුට මෙය නරක අදහසක් වන්නේ මන්දැයි වටහා ගත යුතුය .

මෙය උස නියෝගයකි. ඔහුගේ මනස වෙනස් කිරීමෙන් පසු මුහුණ බේරා ගැනීමේ ගැටලුවට අමතරව, මූලික වශයෙන් පුද්ගල දෝෂාරෝපණය අනුව විසඳුම් ගැන සිතන පුද්ගලයින් සාමාන්‍යයෙන් එම මානසිකත්වය තුළ පිහිටුවා ඇත.

ඔබ මෙම මාතෘකාව මත ලිවීමට ඉල්ලා සිටි අතර පීපල්වෙයාර් මතකයට එයි. එය බෙහෙවින් සලකනු ලබන අතර ප්‍රතිදානය මැනීමට අපහසු තැනක නිර්මාණාත්මක කාර්යයන් කරන පුද්ගලයින් කළමනාකරණය කරන්නේ කෙසේද යන්න පිළිබඳව පොදුවේ කථා කරයි. ගැටලුව වන්නේ ඔබ එය කියවීමෙන් බොහෝ ප්‍රයෝජනවත් නොවනු ඇත, ඔබේ ලොක්කාට එය කියවීමට සිදුවනු ඇති අතර අවම වශයෙන් එයින් සමහරක් වත් විශ්වාස කරන්න.

නියමාකාරයෙන්, මෙහි ඇති ගැටලුව දෝෂ වාර්තා වලට වඩා මිනිසුන් ගැන වන හෙයින්, එය බොහෝ විට වැඩ සටහන් වලට අයත් වන්නේ ක්‍රමලේඛකයන්ට වඩා ය. නමුත් මෘදුකාංග ව්‍යාපෘතිවල සාර්ථකත්වය සාමාන්‍යයෙන් මිනිස් සමාජ අන්තර්ක්‍රියාකාරිත්වයට බෙහෙවින් ඉවහල් වේ, එබැවින් සැබෑ පිළිතුරු බොහෝ විට මෘදුකාංග ඉක්මවා යන දේවල් පිළිබඳව වේ.

මගේ එකම, අඩ බැරෑරුම්, යෝජනාව නම් (හෝ ඔබ පිටත්ව යාමට අදහස් කරන බැවින් සම සේවකයෙකුට පැවසීමට ඒත්තු ගැන්වීම) ව්‍යාපෘතියේ සාර්ථකත්වය පිළිබඳ සම්පූර්ණ වගකීම භාර ගැනීමට ඔබ කැමති , ඔබේ නම සැමවිටම ක්ෂේත්‍රයට යා යුතුය. , වෙනත් අයෙකු කෙලින්ම වැරැද්දක් කළත්, කණ්ඩායමේ සිටින සියල්ලන්ම ගුණාත්මක වැඩ කරන බවට වග බලා ගැනීමේ වගකීම ඔබ භාරගෙන ඇත.

ඇත්ත වශයෙන්ම එය විකාරයකි, ඔබ එය කවදා හෝ උපස්ථ කරන්නේ කෙසේද, නමුත් සමහර අය (විශේෂයෙන් දොස් පවරන විශාල පුද්ගලයින්) ඇත්තෙන්ම එම දේවල් අනුභව කරති. රොනල්ඩ් රේගන් සිය පරිපාලනයේ ඕනෑම සාමාජිකයෙකු අපකීර්තියකට හසු වූ සෑම අවස්ථාවකම (සහ ස්වල්ප දෙනෙක් සිටියහ) පුද්ගලික වගකීම ප්‍රසිද්ධියේ පිළිගැනීමට පුරුදුව සිටියේය. ඔබට ඇති හොඳම කොටස නම් වගකීම සාමාන්‍යයෙන් සැබෑ ප්‍රතිවිපාක නොලැබීමයි, ඔවුන් සිතන්නේ ඔබ වගකීම භාර ගැනීම සඳහා නැගී සිටින පුද්ගලයෙක් බවයි.

එසේත් නැතිනම් එය පහත වැටෙනු ඇත. එය මට කිසිසේත්ම තේරුමක් නැති නිසා එය ක්‍රියාත්මක වන්නේ කවදාදැයි අනාවැකි කීම මට අපහසුය, නමුත් ව්‍යාපාරයක් නොමැති බව පෙනෙන විට එය ක්‍රියාත්මක වන බව මම දැක ඇත්තෙමි (රැකියා ස්ථානයේ, රේගන් උදාහරණය පමණක් නොවේ).

මීට පෙර කිසිවෙකු මෙය සඳහන් නොකිරීම පුදුමයකි: දෝෂ ක්‍රියාකාරීත්වයට එවැනි ක්‍රියාකාරීත්වයක් එක් කිරීම මඟින් පද්ධතිය ක්‍රීඩා කිරීමට උත්සාහ කිරීමට සේවකයින් පොළඹවනු ඇත ඇත.

වෙනත් සමාන අදහස් අතර ඉදිරිපත් කළ ප්‍රශ්නය වැනි ප්‍රවේශයන් සඳහා මෙය පොදු ගැටළුවක් වේ (කේත රේඛා ගණන අනුව ගෙවීම, දෝෂ ගණන අනුව ගෙවීම). මෙය ඔවුන් වැඩ කරන මෘදුකාංගයට අදාළ ගැටළු විසඳීම වෙනුවට හොඳ ලකුණු ලබා ගැනීම කෙරෙහි අවධානය යොමු කිරීමට බොහෝ දෙනා දිරිමත් කරනු ඇත.

නිදසුනක් වශයෙන්, තමන්ගේම වරදක් අඩු කර ගැනීම සඳහා වචන සහිත දෝෂ වාර්තාවක් ඉදිරිපත් කිරීමට උත්සාහ කිරීම සහ එය වෙනත් කෙනෙකුට හෙළීම සංවර්ධකයින් විසින් ගැටලුවේ හේතුව වරදවා වටහා ගැනීමට හේතු විය හැකිය (නැතහොත් එම කොටස නොදන්නා වෙනත් සංවර්ධකයෙකුට ලබා දෙන වැඩ. කේතයක් එය මත වැඩිපුරම වැඩ කළ සහ දෝෂයේ මූලික හේතුව කවුද යන්න තරම් හොඳය) ගැටළුව විසඳීමට වැඩි කාලයක් හා වෑයමක් දරයි.

වැරදි සිදුකිරීමේ අභිප්‍රායයෙන් මිනිසුන් වැඩට නොයනු ඇති අතර, මිනිස් වැරැද්දක් විය හැකි හෝ නොවිය හැකි දේට නිශ්චිතවම දොස් පැවරීම සඳහා උපාය මාර්ග සකස් කිරීම හාස්‍යයට කරුණකි - අතිශයින්ම වෘත්තීයමය නොවන බව සඳහන් නොකිරීම.

අවම වශයෙන්, වගකීම භාර ගැනීමට සහ ගැටලුව "විසඳීමට" පවරා ඇති "වගකිවයුතු පාර්ශවයක්" හෝ සමාන සිදුවීම් සොයා ගැනීමට සහ / හෝ වැළැක්වීමට සැලැස්මක් ඉදිරිපත් කිරීම හොඳ වනු ඇත. සමහර විට විසඳුම අතිරේක පුහුණුවට වඩා වැඩි දෙයක් නොවේ. "රැකියා ගෙවන / සමාගම් කාලය" අධ්‍යාපනයක් ලබා ගැනීම සඳහා මම ඔබේ රැකියා විස්තරයේ කොටසක් වූ සමාගම් ගණනාවක වැඩ කර ඇත්තෙමි. එක් ස්ථානයක් සමස්ත "පුහුණු මධ්‍යස්ථානයක්" පවා ඉදිකර ඇති අතර, දේශීය විද්‍යාලය ඔවුන්ගේ කාර්මික තාක්ෂණ පා .මාලා සඳහා වරින් වර "ණයට ගනී".

මම පසුගිය වසර 20 ක කාලය තුළ නිෂ්පාදන පරිසරයක වැඩ කර ඇති අතර, ක්‍රමලේඛන දෝෂ නිසා දෝෂ ඇති නොවේ, ඒවා භෞතිකව දේවල් විනාශ කරයි, සහ / හෝ ඊටත් වඩා නරක නම්, ඔවුන් මිනිසුන්ට හානියක් කරයි. කෙසේ වෙතත්, සෑම නිෂ්පාදන ක්‍ෂේත්‍රයකම ශක්තිමත්ව පවතින එක් නියතයක් නම්, කිසි විටෙකත්, කිසිදු තත්වයක් යටතේ, කිසිවෙකුට දොස් පැවරිය නොහැකි වීමයි. එය පද්ධතියේ අඩුපාඩුවක් නිසා, සරල හා සරල - මිනිසුන්ගේ අඩුපාඩුවක් නොවේ . මේ ආකාරයෙන් බලන්න - අක්ෂර වින්‍යාස පරීක්ෂකය භාවිතා කිරීම - ඉතා effective ලදායී මෙවලමක්, පා ual මය කුසලතා ක්ෂේත්‍රයේ අඩු වාසනාවන්තයින් සඳහා හෝ සමහර විට මඳක් වැඩ කළ අය සඳහා ... නමුත් කිසිසේත් දොස් පැවරීමේ හෝ වගවීමේ ක්‍රමයක් නොවේ.

වැඩ කරන පරිසරයක්, කුමන ආකාරයේ වුවත්, එය කුමන අරමුණක් සඳහා සේවය කළත් පද්ධතියකි. තනි සංරචක වලින් සෑදී ඇති පද්ධතියක්, නිසි ලෙස “තානයෙන්” නම්, සම්පුර්ණයෙන්ම එකඟතාවයකින් ක්‍රියා කරයි - හෝ එවැනි යම් සමානකමක්.

ඔබේ ලොක්කාගේ කොටසෙහි යෝජිත කියවීම: ඉහළ ective ලදායී පුද්ගලයින්ගේ පුරුදු 7

යථාර්ථය පරීක්ෂා කිරීමක් නොවන්නේ නම් ඔහුට සුළු නිහතමානිකමක් භාවිතා කළ හැකි බව පෙනේ. ඔහු අනෙක් සියල්ලන් මෙන් කණ්ඩායමේම කොටසක් වන අතර, ඔහු එය වටහා ගත යුතුය - නැතහොත් එය ක්‍රියා නොකරනු ඇත, අවසානයේදී ඔහු නොසලකා බෑගය රඳවා ගනු ඇත.

ඔබේ පැත්තෙන් යෝජිත කියවීම සහ / හෝ පර්යේෂණ:

විශ්ලේෂණය, මූල හේතු විශ්ලේෂණය 5 ක් ගැන සොයා බලන්න ... ඔබට විසඳුමක් ලබා දීමට වඩා හොඳ තත්වයකට ගෙන එන ඕනෑම දෙයක් ගැටළුවක් නොවේ . ඔබේ ලොක්කා සමඟ ඇති ඔබේ එකඟ නොවීම, ගැටලුවක් මිස විසඳුමක් නොවේ. ඔහුට වඩා හොඳ දෙයක්, අර්ථවත් යමක් ඉදිරිපත් කරන්න, එම අදහස සඳහා ගෞරවය ලබා ගැනීමට ඔහුට ඉඩ දීමට පවා සූදානම් වන්න.

මේ වන විට ඔහු කිසිවක් නිවැරදි කිරීමට සුදානම් බවක් නොපෙනේ, මන්ද ඔහු කැඩී ඇති දේ පිළිබඳ ස්ථිර අවබෝධයක් නොමැති නිසා, කිසියම් දෙයක් කැඩී ඇත්නම් - ඔහුගේ "මම ලොක්කා" මානසිකත්වය හැර.

වාසනාව! සැමට පිළිගත හැකි අයුරින්, විශේෂයෙන් මේ කාලවලදී ඔබ මෙය හරහා යාමට සමත් වනු ඇතැයි මම බලාපොරොත්තු වෙමි.

සංස්කරණය කරන්න: පුද්ගලිකව, මගේම අත්දැකීම් වලින් ... "ඉදිරියට යන්න, මට දොස් කියන්න. නිසැකවම, මම එය නිවැරදි කර පාරට බැස, එය නැවත සිදු වූ විට, දවස ඉතිරි කර ගැනීමට කවුරුන් පැමිණෙනු ඇත්ද? ඔව්, ඔබ එය අනුමාන කළා ... මම, ලොකු ඔලුවකින්. "

වගවීම සඳහා මට person to blameක්ෂේත්‍රයක් අවශ්‍ය නොවනු ඇත , මට Person who knows the codeක්ෂේත්‍රයක් හෝ ක්ෂේත්‍රයක් අවශ්‍ය වනු ඇත person who can fix, එවිට ආධාරක ටිකට් පත යැවිය යුත්තේ කොතැනට දැයි දැන ගැනීමට මට හැකි වනු ඇත.

මෙය දෝෂය නිවැරදි කිරීමේ ක්‍රියාවලිය වේගවත් කර වගවීම ලබා දෙනු ඇත, එක් ගලකින් කුරුල්ලන් දෙදෙනෙකු killing ාතනය කිරීම වැනි ය. මම මෙය පෞද්ගලිකව ඔහු වෙත ගෙන එනු ඇති අතර, එය අසාර්ථක යැයි කිසිවෙකුට හැඟීමෙන් තොරව චිත්ත ධෛර්යය සහ වගවීම වැඩි කිරීමට මෙය උපකාරී වේදැයි තීරණය කිරීමට ඔහුට ඉඩ දෙන්න. අධික පරීක්ෂාව මඟින් සියලු දෝෂ හඳුනා නොගනී, එසේ නොමැතිනම් දෝෂ වාර්තා කිරීමක් සිදු නොවේ.

"දොස් පැවරීම" .ණාත්මක බව ඔහුට කියන්න. එය "නිවැරදි කිරීමට පුද්ගලයා" ලෙස වෙනස් කරන්න, එවිට අවම වශයෙන් එය ධනාත්මක ආකාරයකින් රාමු කර ඇති අතර, එම කාර්යය තවමත් සිදු වේ. මිනිසුන්ට “දොස් පැවරුවහොත්” ඔවුන් වැඩ කරන්නේ කෙසේද?

මගේ ලොක්කා එසේ කළේ නම් පහත දැක්වෙන දේ සිදුවනු ඇත.

1) මම වහාම නව රැකියාවක් සෙවීම ආරම්භ කරමි.

2) යම් පුද්ගලයෙකුට දෝෂාරෝපණය කිරීමට දෝෂයක් වාර්තා වූ සෑම අවස්ථාවකම, මගේ ලොක්කාගේ නම එහි දිස්වනු ඇති අතර, කණ්ඩායමේ නරක ක්‍රියාවලියක් එයට වගකිව යුත්තේ මන්ද යන්න පිළිබඳ අදහස් දැක්වීමක්. සීසී එය ඔහුගේ ලොක්කාට (වඩාත් සුදුසු කණ්ඩායමක). ඔබට ඒකක පරීක්ෂණ තිබේද? එසේ නොවේ නම් එයින් අදහස් වන්නේ dev ක්‍රියාවලිය බිඳී ඇති බැවින් දෝෂයයි. සියලුම බාහිර පද්ධති සමඟ ඔබට නිරන්තර ස්වයංක්‍රීය ඒකාබද්ධතා පරීක්ෂණ තිබේද? එවිට dev ක්‍රියාවලිය බිඳී ඇත, මේ අනුව දෝෂය. මිනිස් වැරැද්දට ඉඩ නොතබන ලෙස නිෂ්පාදනයේ සෑම පරිසරයක්ම ස්ක්‍රිප්ට් හරහා සමාන කිරීමට ඔබට හැකියාවක් තිබේද? එවිට dev ක්‍රියාවලිය බිඳී ඇත, මේ අනුව දෝෂය. එක් සංවර්ධකයෙක් භයානකද? එවිට බඳවා ගැනීමේ නිර්ණායක නරක ය, එබැවින් ලොක්කාගේ වරදකි. සියළුම සංවර්ධකයින් දිනකට පැය 12 ක් වැඩ කරන නිසා විවේකයක් නොමැතිකම නිසා මෝඩ වැරදි කරන්නේද? එවිට dev ක්‍රියාවලිය කැඩී යයි.

පැති සටහනක් ලෙස: සෑම හොඳ සංවර්ධන කළමනාකරුවෙකුම මා ඉහත ලියා ඇති දේ දැන සිටියි. සහ වේගවත් උපාය මාර්ග යනු දේව් මන්දගාමී වන්නේ මන්දැයි ලොක්කාට හෝ ඔහුගේ / ඇයගේ අතිරේකයන්ට පෙන්වා දීමට ය: බලන්න, අපි අපගේ කාලයෙන් 50% ක්ම දෝෂ නිවැරදි කිරීමට වැය කරමු. ඒවා අඩු කිරීම සඳහා උපාය මාර්ග දෙස බලමු, එවිට අපට දෝෂ නිවැරදි කිරීමට 40% ක් වැය කළ හැකිය, ඉන්පසු මෙම ගැටළුව 30% දක්වා නැවත ලබා ගන්න. ආදිය.

අවාසනාවට, ක්ෂේත්‍රය නිසා ඔබට හොඳ කළමනාකරුවෙකු නොමැති බව පෙනේ. එබැවින් මම යෝජනා කරන්නේ (1) එය කළමනාකරු වෙත ගෙන නොයන්න (ඔබගේ පිටවීමේ සම්මුඛ පරීක්ෂණය හැර)

ඔබේ ලොක්කාට මෘදුකාංග පිළිබඳ ගැඹුරු අවබෝධයක් නොමැති බව පෙනේ. සමහර විට ඔහු අදහස් නොකරනු ඇත. එබැවින් ඔහුට වෙනස් භාෂාවක්, වෙනස් සංස්කෘතියක් ඇත.

මෙවැනි ගැටලුවක් සඳහා රැකියාවක් අත්හැරීම, විසඳුමක් සඳහා ඉදිරියට යාමට පෙර පවා එය විකාරයකි. ඉවත්වීම යනු ඉවත්වීමයි. ඔබට කවදාවත් එකිනෙකාව තේරුම් ගත නොහැකි බවට ඔහු සහතික වන තුරු ඉවත්ව නොයන්න. ඒ ගැන සහතික වීමට නම්, ඔබ පළමුව උත්සාහ කළ යුතුය.

ඔහු අපේ භාෂාව නොදන්නා නිසාත්, ඔහු ලොක්කා නිසාත්, මෙහි පළමු පියවර වනුයේ ඔහු සමඟ ඔහුගේ භාෂාවෙන් කතා කිරීමට උත්සාහ කිරීමයි. භාෂාව සමඟ මා අදහස් කරන්නේ කුමක්ද? අපි එකට සිතමු:

අපි මෘදුකාංග මිනිසුන්, අපගෙන් බොහෝ දෙනෙක් අප කරන රැකියාවට ඇලුම් කරන්නෙමු, අප කරන දේ සමඟ ගැඹුරු සම්බන්ධතාවයක් ඇත. එසේ නොමැති නම් එය ක්‍රියාත්මක නොවන අතර කෙනෙකුට මෙම ව්‍යාපාරයට ආදරය නොකර හෝ සම්පුර්ණ නොවී දිගු කලක් ඉදිරියට යා නොහැක ... ඔබ හිස් තැන් පුරවන්න ...

කෙසේවෙතත්, ඔහු දේවල් බොහෝ වෙනස් ලෙස දකී. සෑම දෝෂ වාර්තාවක් සමඟම, අප බොහෝ දෙනා එය වඩා හොඳින් වැඩ කිරීමට උනන්දු වන අතර (නැත, සමහර විට එය ඇත්තෙන්ම ආතතියට පත්වුවද, අපි ගැටලුවලට ඇලුම් කරන්නෙමු, එය පිළිගන්න!), ඔහු එය දකින්නේ අසාර්ථකත්වය, මිනුමකි අසාර්ථකයි. ඔහුට තේරුම් ගැනීමට අවශ්‍ය පළමු දෙය නම් දෝෂ හොඳයි. දෝෂ නිසා ගනුදෙනුකරුවන් සමාගමට ආදරය කරයි. (දැන් මෙය ඔහුගේ භාෂාවයි) ගනුදෙනුකරුවෙකු දෝෂයක් වාර්තා කළ විට, හෝ අප අපවම සොයාගත් විට, එය විසඳූ පසු, එය කිසි විටෙකත් සිදු නොවූ තත්වයට වඩා හොඳය. දෝෂ පාරිභෝගික විශ්වාසවන්තභාවය ඇති කරයි (මම බැරෑරුම් ය!), දෝෂ පාරිභෝගිකයා සහ මෘදුකාංග නිෂ්පාදකයා අතර සන්නිවේදනය සඳහා විශාල නිදහසට කරුණක් නිර්මාණය කරයි.

"දෝෂවල ලාභය වැඩි කිරීම" සඳහා ඔබ දෝෂ වාර්තා වඩාත් විවෘත කිරීමට ඉදිරිපත් කළ යුතුය. සෑම දෝෂ වාර්තාවක් සහ එහි ඉක්මන්, පිරිසිදු, හොඳ විසඳුමක් සමඟ ගනුදෙනුකරුවන්ට දැනෙන අතර "වාව්, මේ අය නියමයි! ඔවුන් ඉතා වෙහෙස මහන්සි වී වැඩ කරයි. ඔවුන් විසඳන මේ දේවල් දෙස බලන්න. මෘදුකාංගය එතරම් සංකීර්ණ බව අපි දැන සිටියේ නැත. දෙයක්! ” blah blah සහ blah ...

ඔබේ පියවර ගන්න, ඔහුගේ භාෂාවෙන් කතා කරන්න. මෘදුකාංග සමාගමකට දෝෂ විශිෂ්ටයි, ගැටලුවක් නොවේ. ඔවුන් අපව ජීවත්වේ.

කණ්ඩායම් ආචාර ධර්ම, කාර්යක්ෂමතාව හෝ ඔබ කරන ඕනෑම ආකාරයක කතාවක් සඳහා ඔබ අදහස් කළ ආකාරයටම ක්‍රියා කළ හැකිය. ඔබට ඉවත් වීමට අවශ්‍ය නම්, ඔහු සිතනු ඇත "ආහා, මගේ විසඳුම පළමු දිනයේ සිටම ක්‍රියාත්මක වීමට පටන් ගත්තේය! නරක සම්බන්ධතා නිරාවරණය වීමට පෙර ඔවුන් විසින්ම අතහැර දැමීමට පටන් ගෙන තිබේ!" සමාගමේ නරක පිරිමි ළමයින් සොයා ගැනීමේ ඔහුගේ අදහස ඔහු විශ්වාස කරන අතර වෙනත් ආකාරයකින් ඔහුට ඒත්තු ගැන්වීම ඉතා අපහසුය. විශේෂයෙන්ම ඔබ එම නරක පිරිමි ළමයෙකු විය හැකි විට!

එබැවින්, ඔහුගේ සැබෑ ගැටළුව කෙරෙහි අවධානය යොමු කරන්න: දෝෂ. දෝෂ ඉතා ප්‍රයෝජනවත් විය හැකි බව ඔහුට පෙන්වන්න. කිසිදු ගැටළුවක් නොමැතිව, සම්බන්ධතාවයක් කම්මැලි ය. ඔබව මරණයට පත් නොකරන සෑම දෙයක්ම ඔබව ශක්තිමත් කරයි. සෑම දෝෂයක්ම පාරිභෝගික සතුට වැඩි කිරීමට ඔබට භාවිතා කළ හැකි හොඳ අවස්ථාවක්.

මෙය ඔබට පැවසිය හැකි එක් දෙයක් පමණි. ඔහුගේ උත්සුකයන් ගැන සිතන්න, ඔබේ ලැයිස්තුවට එක් කිරීමට තවත් බොහෝ අයිතම ඔබ සොයා ගනු ඇත. ගෝල්ඩන් කේ යනු ඔහුගේ අදහස සමඟ සටන් කරනවා වෙනුවට විකල්ප දෙයක් ඉදිරිපත් කිරීමයි!

ඔබ කරන්නේ Agile නම්, එය ඔබ විශේෂාංග / කථා විවරණයෙන් පැමිණි බවක් පෙනේ . මෙම වරද කිරීමට පුද්ගලයා හරහා දෝෂ ගිලිහී යාමට ඉඩ ඇති QA පුද්ගලයා හෝ එය තුළ දෝෂ සමඟ පූර්ණ ලෙස ලක්ෂණය / කතාව පිළිගත් බව නිෂ්පාදන අයිතිකරුෙග් / පාරිභෝගික වනු ඇත.

මම දවසේ යතුරු ලියනය කළෙමි, මෙන්න මම එය භාර ගනිමි.

මෙය හරියට අක්ෂර වින්‍යාස සහ වෙනත් දේ සඳහා යතුරු ලියනයකට දොස් පැවරීම හා සමානයි. යතුරුලියනය අක්ෂර වින්‍යාසය සෑදූ නමුත් සෝදුපත් කියවන්නාට එය මඟ හැරුණි, එබැවින් මුද්‍රණය කිරීමේ වැරැද්දට වගකිව යුත්තේ සෝදුපත් කියවන්නා මිස වැරැද්ද මුලින් සිදු කළ පුද්ගලයා නොවේ .

කඩිනම් පරිසරයක දෝෂ (දෝෂ) හසු කර ගැනීම QA පුද්ගලයන්ගේ වගකීම වන අතර නිවැරදි නොවන දේ පිළිගැනීම නිෂ්පාදන අයිතිකරුවන්ගේ වගකීම වේ. මෙය ඔප්පු කරන පා readers කයන්ගේ මට්ටම් දෙකකි, එය සංවර්ධකයින්ට මුදා හරින දේවලින් පරිවරණය කළ යුතු අතර, ඕනෑම දෙයක් කඩිනම් පරිසරයක දෝෂයක් ලෙස වර්ග කළ යුතු එකම ක්‍රමය එයයි .

මම හිතන්නේ ඔබේ කළමනාකරු වැරදි විසඳුමක් සමඟ ගැටළුවක් විසඳීමට උත්සාහ කරයි. බොහෝ දෝෂ මුදා හැරීමේ ගැටලුවක් තිබිය හැකි යැයි මම සිතමි. ඔබේ කළමනාකරුට අවශ්‍ය වන්නේ සංවර්ධකයින් ඔවුන් ලියන කේතය කෙරෙහි වැඩි හිමිකමක් සහ වගවීමක් ලබා ගැනීමයි.

ටෙස්ට් ඩ්‍රයිව් ඩිවලොප්මන්ට් භාවිතා කිරීම සහ අඛණ්ඩ ඒකාබද්ධ කිරීමේ සේවාදායකයක් ( ජෙන්කින්ස් වැනි ) පිහිටුවීම "දොස් පවරන ක්‍රීඩාව" හඳුන්වා නොදී මෙම ගැටළුව විසඳීමට උපකාරී වේ. අඛණ්ඩ ඒකාබද්ධ කිරීමේ සේවාදායකයක් මේ සඳහා වැදගත් වන්නේ යමෙකු “ගොඩනැගීම බිඳ දැමූ” කේතයක් කළ විට පුද්ගලයාට දොස් පැවරිය යුතු විද්‍යුත් තැපෑලක් කණ්ඩායමට යවන බැවිනි. මෙම කේතය නිෂ්පාදන පරිසරයකට මුදා හැර නොමැති බැවින්, මෙම ආකාරයේ දොස් වඩාත් ක්‍රියාශීලී හා දිරිගන්වන සුළුය (හා විනෝදජනකයි!).

ප්‍රති result ලය වනුයේ සංවර්ධකයින් වැඩි හිමිකාරිත්වයක් ලබා ගැනීම, වැඩි විශ්වාසයක් දැනීම සහ නිෂ්පාදන කේතයේ අඩු දෝෂ ඇති වීමයි.

තනි පුද්ගලයෙකුගේ අත්වැරැද්දක් නිසා නිෂ්පාදනයේ දෝෂයක් ඇති වුවහොත්, ඔබේ ක්‍රමවේදයෙහි හෝ මෘදුකාංග සංවර්ධනය කිරීමේ ඔබේ සියලු ආකාරවල යම් දෝෂයක් ඇති බව පෙන්වා දෙන්න. දෝෂ ඇතිවීම වැළැක්වීම සමස්ත කණ්ඩායමේම වගකීම බව පෙන්වා දෙන්න.

මෙම තර්ක දෙකෙන් එකක් භාවිතා කරමින්, තනි තේරීම් ක්ෂේත්‍රයක් ලෙස “කාට දොස් පැවරිය යුතුද” යන ක්ෂේත්‍රය නොමඟ යවන බව ඔබේ ලොක්කාට ඒත්තු ගැන්විය හැකිදැයි බලන්න; එම නිසා, "කාට දොස් පැවරිය යුතුද" යන ක්ෂේත්‍රය බහුවරණ ක්ෂේත්‍රයක් බවට වග බලා ගැනීම අවශ්‍ය වේ. ඔබ මෙය සාක්ෂාත් කරගත් පසු, සෑම දෝෂයක් සඳහාම, සෑම කෙනෙකුගේම නම ක්ෂේත්‍රයේ ඇති බවට සහතික වන්න. ක්ෂේත්‍රය පිළිබඳ ඕනෑම වාර්තා කිරීම නිෂ් le ල බව ඔබේ ලොක්කා අවසානයේ දකිනු ඇත.

ලොක්කා සමහර ණය ලබා දීම සඳහා, "වරද පැවරුම" සංකල්පය දැනටමත් වැනි මෙවලම් විළඳ ඇත SVN , සහ දත්ත සුදුසු ආකාරයෙන් භාවිතා දෝෂහරණ, උදා: අතර වූ "කතා කිරීමට කවුරුන්ද සොයා" තුළ සංවර්ධකයන් ඵලදායි විය හැක: http: / /www.codinghorror.com/blog/2007/11/who-wrote-this-crap.html

Root Cause ක්ෂේත්‍රය හොඳ දෙයක් බව ඉහත සඳහන් කළ gnat ගේ ප්‍රතිචාරයට මා එකඟ වන අතර , මෙය එකම තොරතුරු නොවන අතර, සමහර විට බලපෑමට ලක්වූ ප්‍රභවය සඳහා පෙර සංවර්ධක නාමය (ය) පැවරීම සඳහා ක්ෂේත්‍රය “අවලංගු කිරීම” සහ සමහර විට a තාක්ෂණික විස්තරය (උදා: "පරිශීලකයින් 10000 ක් දක්වා පරිමාණය නොකළේය") ජලය මඩ වනු ඇත. තබා ගැනීම සඳහා මම පෙනී සිටිමි මූල හේතුවක්ක්ෂේත්‍රය පැහැදිලිවම තාක්ෂණික විස්තරයක් (උදා: පැහැදිලි ක්‍රමලේඛක දෝෂයක් ඇති විටදී පවා, "fooData = 999 විට IndexOutOfRange Exception" වැනි තොරතුරු ග්‍රහණය කර ගෙන තිබේ නම්) මෙය විශාල වශයෙන් සමාලෝචනය කරන විට ප්‍රයෝජනවත් ප්‍රතිපෝෂණ ලබා දිය හැකි අතර සමහර නිවැරදි කිරීමේ ක්‍රියාමාර්ග ගැනීමට ඉඩ ලබා දේ. වාස්තු විද්‍යාත්මක හෝ රාමු වෙනස්වීම් සමඟ ඇති සමස්ත පංති විසඳීම සඳහා (උදා: අභිරුචි බහාලුම් පන්ති වැඩි දියුණු කිරීම, ඉහළ මට්ටමේ ව්‍යතිරේක භාරදීම)

එයින් කියැවෙන්නේ පුද්ගලයෙකුට දොස් පැවරීමේ ක්ෂේත්‍රයක් පැහැදිලිව එකතු කිරීමෙන් මෘදුකාංග කණ්ඩායමකට ඉතා නරක පණිවිඩයක් සහ විනාශකාරී පණිවිඩයක් යැවිය හැකි අතර කළමනාකරණයට අවශ්‍ය වන්නේ කේතය කඩ කරන තනි සංවර්ධකයින්ට තනිවම ද punish ුවම් කිරීමටය. මෙම "ලැජ්ජාවේ බිත්තියට" ඔවුන්ගේ නම් ලබා ගැනීමෙන් වළක්වා ගැනීම සඳහා සංවර්ධකයින් වඩාත් පරිස්සමින් හා ස්වයං-නියාමනයකට ලක් කරනු ඇතැයි කළමනාකරු විශ්වාස කරන අතර, සංවර්ධකයින්ට මෙයින් තර්ජනයක් දැනෙන්නේ මන්දැයි නොතේරේ, විශේෂයෙන් එය එකතු කළහොත් සෑම දෝෂ වාර්තාවකටම සාමාන්‍යයෙන්.

මෙය දෝෂ ක්ෂේත්‍රයක් / විභව මෙට්‍රික් එකක් ලෙස එකතු කිරීමේ ගැටළු ගණනය කිරීම ආරම්භ කිරීම පහසුය:

1. දෝෂ නිරාකරණය කිරීමේ දුෂ්කරතාවයේ ඉහළ විචල්‍යතාවයක් ඇති අතර දෝෂ ගණනය කිරීමේ / සංවර්ධකයාගේ සරල සංඛ්‍යාලේඛනයක් මෙය පිළිබිඹු නොකරයි.
2. සංවර්ධකයින්ගේ හැකියාවන්හි ඉහළ විචල්‍යතාවයක් ඇත "" "" "" "" "" ""
3. බොහෝ මෘදුකාංග පද්ධතිවල ප්‍රතිචක්‍රීකරණය අවශ්‍ය වන සංරචක ඇත, කෙසේ වෙතත් පැරණි කොටස් නැවත ප්‍රතිනිර්මාණය කිරීම (විශේෂයෙන් උරුම පදනමට / සීමිත ඒකක පරීක්ෂණ පහසුකම් නොමැති නම්) මුලින් දෝෂ හඳුන්වා දෙනු ඇත. නව දෝෂ උත්පාදනය කිරීම හා සම්බන්ධ අපකීර්තියක් / බියක් තිබේ නම් (මේවා විසඳීමට සුළු කාරණයක් වුවද අවසාන ප්‍රති result ලය පද්ධතියේ විශාල දියුණුවක් වුවද) සංවර්ධකයින් මෙම “හොඳ” ක්‍රියාකාරකමෙන් අධෛර්යමත් වීමට ඉඩ ඇත.
4. වඩාත් සවිස්තරාත්මක විශ්ලේෂණයක් සිදු නොකරන්නේ නම්, පරීක්ෂකයින් එකම ගැටළුවට අදාළව ඉතා විචල්‍ය දෝෂ සංඛ්‍යාවක් ගොනු කළ හැකිය.

එය අයිස් කුට්ටියේ අගයක් පමණි. ඒපීඅයි හැසිරීම, පරීක්ෂණවල වැරදි අපේක්ෂිත ප්‍රති results ල සහ වැරදි / නැතිවූ අවශ්‍යතා සහිත “පෙර දාමයේ” ගැටළු අපේක්ෂා කළේ කවුරුන්ද යන්න ඇඟිල්ල දිගු කිරීම සමඟ මේවා ඒකාබද්ධ කරන්න, මෙවැනි මෙට්‍රික් එකක් වටිනාකමක් නැති බව පෙනේ නම් (හැර) ඉලක්කය වන්නේ චිත්ත ධෛර්යයට හානි කිරීම සහ විශාල වශයෙන් නික්මයාම ඇති කිරීමයි.)

ලොක්කාගේ දෘෂ්ටිකෝණයට ආපසු, ඔහුට / ඇයට අවශ්‍ය වන්නේ නැවත නැවතත් කේතය කඩන සංවර්ධකයින් සිටීද යන්න සොයා බැලීම සහ ඒ පිළිබඳව යමක් කිරීමට (බලාපොරොත්තු සහගත ලෙස ruc ලදායී) උත්සාහ කිරීම සහ කිරීම ය. දෝෂ වාර්තා සඳහා ක්ෂේත්‍රයක් එකතු කිරීමෙන් මෙම තොරතුරු ලබා ගැනීමට උත්සාහ කිරීම ඉහත ලැයිස්තුගත කර ඇති හේතු සඳහා අර්ථවත් තොරතුරු සපයන්නේ නැත. මගේ අත්දැකීම් අනුව, කණ්ඩායම සමඟ සම්බන්ධ වීම, කණ්ඩායම් රැස්වීම් බොහොමයකට සහභාගී වීම, කණ්ඩායම් සාමාජිකයන් සමඟ වරින් වර එක වර රැස්වීම් වලදී ඉගෙන ගත් තොරතුරු (ප්‍රවේශමෙන්) ඒකාබද්ධ කිරීම සහ උප පද්ධති සමඟ හුරු වීමෙන් මෙම තොරතුරු ඉගෙන ගත හැකිය. කේතය (ඔවුන්ට කේතය කියවිය නොහැකි වුවද)

එයට ඉඩ දෙන්න. එය ගැටළුවක් ඇති වුවහොත් එය ඔබගේ ලොක්කා විසින්ම සොයා ගනු ඇත.

මොට වීමට ඉඩ දෙන්න, ඔබට මතයක් ඇති අතර ඔහු එසේ කරයි. ඔහු ඔබේ කළමනාකරු වන අතර ඔහුගේ මතය ජය ගනී.

ඔව්, ඔබට මෙම ප්‍රශ්නය සම්බන්ධයෙන් යුද්ධයට යා හැකිය, නමුත් එය ඇත්තෙන්ම වටී ද? එය අක්‍රිය වීමට මාස 3 කට වඩා වැඩි කාලයක් පවතින බව මට සැකයි.

නමුත් මෙය සක්‍රියව කඩාකප්පල් කිරීම හෝ ඒ ගැන කෑගැසීම, එම අමතර කාලය, ඊළඟ නැගීම, උසස් කිරීම හෝ සැබවින්ම තීරණාත්මක සැලසුම් තීරණයක් ගැනීමට යන විට ඉල්ලීම සඳහා වඩා හොඳ ඉතිරියක් ඇති දේශපාලන ප්‍රාග්ධනය භාවිතා කරයි.

ඒ මොහොතේදී, එය සැබවින්ම ගණන් කරන විට, "පුද්ගලයාට දොස් පැවරීම" සඳහා ඔහුගේ අදහස සක්‍රියව කඩාකප්පල් කළ පුද්ගලයා ඔබ බව ලොක්කා මතක තබා ගැනීමට ඔබට අවශ්‍යය.

ඔබ තීරණයට ගරු නොකළත් කාර්යාලයට ගරු කරන්න.

දිගු කල් පවතින තීරණ සඳහා ආතතිය සහ මේස පහරවල් ඉතිරි කරන්න.

කණ්ඩායමක් තුළ වර්ධනය වීමට සමාජ කුසලතා අවශ්‍ය බව ඔබේ ලොක්කාට කියන්න. ඔහු විහිළු කරයි.

නමුත් ගැටළුව වන්නේ මෙය සංවර්ධකයින් සමඟ අතිශයින්ම නරක දෙයක් වීමයි. නිසි ගැටළු විශ්ලේෂණයට වඩා දොස් පැවරීම යෝජනා කරන මෙවලම් එකතු කිරීම ප්‍රති- tive ලදායී වේ.

ඒ වෙනුවට ඔබට සමාජ කුසලතා වැඩි දියුණු කිරීම සඳහා දිරිගැන්වීම් අවශ්‍ය වන අතර ඔබ සතුව ඇති සන්නිවේදන යටිතල පහසුකම් ඊට සහාය විය යුතුය. උදාහරණයක් ලෙස, එය ධනාත්මකව කාසි කරන්න: ටිකට් පතකට වගකිව යුතු, එය බලා ගන්නා පුද්ගලයෙකු නම් කරන්න.

කේත සමාලෝචන සමඟ ආරම්භ කරන්න එවිට ඔබට එකිනෙකාගෙන් ඉගෙන ගත හැකිය. එය පසුකාලීනව දොස් පවරයි.

ඔහුට මෙම SO ප්‍රශ්නය යොමු කරන්න. ඔහු තර්කානුකූලව විවෘත නම්, මෙහි දැක්වෙන අදහස් ඔහුගේ තර්කනය සඳහා සනීපාරක්ෂක චෙක්පත් ලබා දෙනු ඇත. ඔහු සාධාරණ නොවේ නම්, ඔබට තේරුමක් ඇති හේතු ඔහුට ඒත්තු ගැන්වීමට අපහසුය. ඊට අමතරව, සංවාදයකට පිටතින් ඇති හේතු කියවීමට ඔහුට හැකි වනු ඇත (සංවාදයක උණුසුම තුළ “නිවැරදි වීමට” ඉවත් කරන ලද පෙළඹවීම නිසා සමහර විට එය වඩාත් ඒත්තු ගැන්විය හැකිය).

ඔබට එය හැරවීමට උත්සාහ කළ හැකිය. ක්ෂේත්‍රය “සමාන දෝෂයක් ඇතිවීම වළක්වා ගත හැකි පියවර” හෝ ඒ සඳහා කෙටි යමක් විය හැකිය. එවිට ඔබට විසඳුම් රැස් කර ඔබගේ සේවා ස්ථානය වඩා හොඳ කිරීම සඳහා ක්‍රියාත්මක කළ යුතු ඡන්දය ප්‍රකාශ කළ හැකිය. සමහර විට විසඳුම්-නැඹුරු ප්‍රවේශයක් වඩා tive ලදායී වන අතර වඩා හොඳ ප්‍රතිචාරයක් ලැබෙනු ඇත (යෝජනා නැවත සලකා බැලීමේදී සත්‍ය අනුගමනය කිරීමක් තිබේ නම්).

මම මෙහි අවස්ථා දෙකක් දකිමි: ඔහුට අවශ්‍ය වන්නේ වැරදි කරන අයට ද punish ුවම් කිරීමට හැකිවීම හෝ ඔහු ඒ ගැන නොසිතීමයි. සෑම කෙනෙකුම වටහා ගන්නා දෙය නම් ඔහු වැරදි කරන අයට ද punish ුවම් කිරීමට අදහස් කරන බව ඔහුට දන්වන්න. ඔහුට ධෛර්යමත් කිරීමට අවශ්‍ය සංස්කෘතිය එයදැයි ඔහුගෙන් විමසන්න.

අපගේ ලොක්කා තීරණය කළේ අපගේ දෝෂ ලුහුබැඳීමේ අච්චුවට "දොස් පැවරිය යුතු" ක්ෂේත්‍රයක් එක් කිරීමෙන් වගවීම වැඩි වන බවයි

මගේ අත්දැකීම් අනුව, කළමනාකාරිත්වයට "මිනිසුන්ව වඩාත් වගකීමෙන් යුතුව" කිරීමට අවශ්‍ය වූ විට, ඔවුන් අදහස් කරන්නේ අසාර්ථකත්වයට නිශ්චිත ද punishment ුවම් ලබා දීමට ඔවුන්ට අවශ්‍ය බවය. එය දුප්පත් රංගන ශිල්පීන්ට වෙඩි තැබීම හෝ වාර්ෂික වැටුප් සමාලෝචනයේදී ඔවුන්ව ගිල දැමීමට ඉඩ හැරීම ("කණගාටුයි, බොබ්, ඔබේ දෝෂය ලෙස දෝෂ 17 ක් සලකුණු කර ඇති අතර එය 15 සීමාව ඉක්මවා ඇත"), එය ද punishment ුවමකි.

ඔහු බොහෝ විට "ඔහ්, නෑ, අපට එය අවශ්‍ය නැත" යැයි කියනු ඇත, එබැවින් එම දත්ත භාවිතා කරන්නේ කෙසේදැයි ඔහුගෙන් විමසන්න. ඔබ දත්ත ගබඩාවක් භාවිතා කිරීමට යන්නේ නම් මිස දත්ත ලකුණු එකතු නොකරන බව ඔහුට මතක් කරන්න. ඔහුට ලබා දී ඇති නිර්ණායකයක් මත තෝරා ගැනීමට අවශ්‍යද ("වාර්තා නිර්මාතෘ උප පද්ධතියේ ඇති සියලුම විවෘත දෝෂ මට පෙන්වන්න"), එවිට ඔබට දේවල් මත වැඩ කිරීමට හෝ සමස්ත දත්ත ලබා ගැනීමට හැකි වනු ඇත ("වැඩිපුරම ඇත්තේ කුමන උප පද්ධතියටද? දෝෂ "), එවිට ඔබට පශ්චාත් මරණ පරීක්ෂණ කළ හැකිය. මිනිසුන්ට ප්‍රසිද්ධියේ අවමානයට ලක් කළ හැකි යම් ආකාරයක අසාර්ථක පුවරුවක් ඔහු සිතන්නේද?

ඉතින් ඔහු අදහස් කරන්නේ කුමක්ද? "බොබ්ගේ වරදක් වන සියලු දෝෂ මට පෙන්වන්න" යනුවෙන් පැවසීමට ඔහුට අවශ්‍යද? මන්ද? නැතහොත් "බොහෝ විට වැරැදි කළ තැනැත්තා මට පෙන්වන්න" යනුවෙන් පැවසීමට ඔහුට අවශ්‍යද? මන්ද? පළමුවැන්න අර්ථවත් නොවන අතර දෙවැන්න ද itive ුවම් පමණි. නැතහොත් තුන්වන විකල්පය නම් ඔහුට සැබෑ හේතුවක් නොමැති වීමයි.

කණ්ඩායමේ නිපුණතා වැඩි දියුණු කිරීම සඳහා උපකාර අවශ්‍ය වන එම ක්‍රමලේඛකයින් ඔහු සෙවීමේ හැකියාවක් ඇති බව මම පිළිගනිමි. එසේ නම්, ඇඟිලි තුඩු දීමේ සංස්කෘතියක් ඇති නොකරන මෙම තොරතුරු ග්‍රහණය කර ගැනීමට වඩා හොඳ ක්‍රම තිබේ.

මෙහි දී නැරඹිය යුතු ප්‍රධාන අංගය වන්නේ 'ලොක්කා' වෙත කණ්ඩායම තුළ සන්නිවේදනය කෙතරම් විවෘතද යන්න සහ අනෙක් පැත්තෙන්. ඇඟිලි තුඩු ගැසීම කිසි විටෙකත් යහපත් නොවේ, කෙසේ වෙතත්, කළමනාකරණ දෘෂ්ටි කෝණයකින්, ඔබේ සංවර්ධකයෙකු කිහිප වතාවක්ම එකම ගැටලුවකට වැටුණහොත්, එය නැවත නැවත මෙම ගැටලුව මඟහරවා ගැනීමට ඔහුට උදව් කිරීමට උත්සාහ කළ හැකිය (උදා: ජෝන් නිසි ලෙස පරීක්ෂා නොකරයි කේතය: පසුගිය මාස 3 තුළ නිෂ්පාදන දෝෂ 3 ක්, අපි ඔහුට පිරික්සුම් ලැයිස්තුවක් ලබා දෙමු, එවිට ඔහුගේ කේතය කෙසේ විය යුතුද යන්න සහ ඔහු එය පරීක්ෂා කළ යුතු ආකාරය මතක තබා ගනී).

සංවර්ධන දෘෂ්ටි කෝණයකින්, 'දොස් පැවරීම' දැනටමත් එස්.වී.එන් වැනි ප්‍රධාන ධාරාවේ මෙවලමකට ඇතුළත් කර ඇත, එබැවින් "ජෝන්, කරුණාකර ඔබ ලියා ඇති කපටිකම නිවැරදි කරන්න" සහ නමක් අසල තැබීමෙන් මට කිසිදු හානියක් නොපෙනේ. එය. ඔබ දෝෂයක් ගොනු කරන විට ජිරා පුද්ගලයෙකුගේ නමද ඇතුළත් කරයි (කෙසේ වෙතත් එය ඇත්ත වශයෙන්ම වගකිව යුතු පුද්ගලයා සඳහා අදහස් නොකෙරේ, එය නිවැරදි කිරීමට යමෙකු එය නිවැරදි කරයි).

මෙන්න කාරණය නම්, බොහෝ දෙනා ඉහත සඳහන් කළ පරිදි, දෝෂයක් ඇති වුවහොත් එය හවුල් වගකීමකි: සංවර්ධකයාගේ සිට පරීක්ෂකයින්ගේ සිට QA දක්වා සහ කළමනාකරුවන් දක්වා. ඔබේ ලොක්කා යම් වේලාවක කෝපාවිෂ්ට සේවාදායකයකු දුරකථනයෙන් හසුරුවන්නේ නම් " මට කණගාටුයි, ජෝන් කිසි විටෙකත් මෙය නිසි ලෙස පරීක්‍ෂා නොකළේය " වැනි දේ සමඟ මම අනිවාර්යයෙන්ම වෙනත් රැකියාවක් සොයනු ඇත. හොඳ ලොක්කෙක් යා යුතුයි "අපි මේ ගැන බලාගන්නම්". නම් නැත, ඇඟිලි තුඩු නැත, විසඳුම් පමණි.

නැවතත්, මම විශ්වාස කරන්නේ ඒ සියල්ල සන්නිවේදනය බවයි. සමහර විට ඔබේ ලොක්කාට කිරීමට අවශ්‍ය එකම දෙය වන්නේ ඩිව් කණ්ඩායමේ කරදර ඇති අය හෝ කණ්ඩායමට ඇති ගැටළු මොනවාද (සමහර විට පුහුණු සැසි සඳහාද?) දැකීමයි, නමුත් ඔහුගේ පිටුපස ඇති දේ ඔබ හරියටම සොයා ගනී යැයි මම නොසිතමි. ඔබ ඔබේ ලොක්කා සහ ඔබේ මුළු කණ්ඩායම සමඟ කතා නොකරන්නේ නම් තීරණය (හෝ වඩා හොඳින් කිවහොත්, අපි පෝස්ටර් / පා readers කයින්).