Tag Requirement

สรุปปัญหาที่จาก Site งานแห่งหนึ่ง

วันนี้ครบ 8 ปี ของโปรเจคมหากาพย์ ระบบงานลงทุน ครับ จากตอนแรกที่ประเมินไว้ 3,000 กว่า man day แต่บริษัทต้องทำให้ได้ใน 1 ปี สิ่งที่พูดมันดูท้าทาย เพราะ เรามี Standard Package รอแล้ว Marketing กล่าวอย่างมั่นใจ เมื่อผ่านไป 1 ปี เจ้า Standard Package มันจะกลายเป็น Special Package หรือป่าวนะ ลองดูปัญหากัน ฝั่ง PM/BA ผู้ใกล้ชิดกับ User ฝั้ง SA/Dev บ้าง…

สื่อสารผิดพลาด ราคาลงเป็น 10 เท่า

หุ้น

Blog อันนี้เขียนบันทึกไว้ แต่ดองไว้สักพักใหญ่ๆก่อน เพราะ ที่เขียนมาจากทวิตของ 9arm เลยนึกถึงเรื่องนี้ได้ครับบ เรื่องของเรื่อง คือ ลูกค้าจ้าง Customize Module นึงมา แล้วขอให้มีการแจกแจงราคาครับ ฝั่ง Develop ช่วยแจกแจงว่า ถ้าทำ Module แบบไหนใช้เวลาเท่าไหร่ และมีอธิบายฝ่าย MKT ดังนี้ Module Process (Man-day) Export ( Man-day) Total ( Man-day) A 20 2 22 B 35 3 38…

คิดให้เยอะ ลงมือทำให้น้อยที่สุด

หลายๆคนอาจจะเคยเห็นภาพนี้แล้วนะครับ มันสื่อถึงอะไร หละ ? บางคนอ่านแล้ว ก็หัวเราะเลย บางคนยังไม่ Get  จากภาพนี้ในมุมของผม ตีความถึงการมองปัญหาครับ ทุกปัญหา เราไม่สามารถใช้วิธีการเดียวกันจัดการกับมันได้ เราต้องค่อยๆลับปัญหาเปลี่ยนมุมมองบ้าง โดยในแง่ของการพัฒนา Software สิ่งที่มาขยาย ปรับ องศา มุมมองที่มีต่อปัญหา ได้แก่ Requirement(ต้องชัดเจน ใช้ได้แค่ทฤษฏีนะ แต่ในความเป็นจริงก็รู้ๆกันอยู่ 555) Skill ที่ใช้ในการวิเคราะห์ปัญหา อันนี้อาจจะต้องใช้ประสบการณ์สะสมนะครับ ว่าแต่ละปัญหาเกิดจากอะไร ตรงนี้เป็นปัญหาสำหรับ Dev ส่วนใหญ่ที่ผมเจอมาเลย คือ เขียนโปรแกรมได้ แต่พอโปรแกรมผิิดขึ้นมา ยังไม่สามารถวิเคราะห์จุดที่ผิดได้ครับ (ตามรูปด้านบนที่ผมเอามาอ้างเลย) ความเข้าใจของคนกลุ่มต่างๆ ต่อชิ้นงานที่ทำ ตั้งแต่ User…