Desain produk dapat terlihat seperti sihir. Ketika saya mulai melakukannya sepuluh tahun yang lalu, tim kecil saya bekerja pada keputusan yang dibuat secara intuitif. Tidak ada sistem dan bekerja dengan baik. Tapi seperti perusahaan tumbuh, saya menemukan diri saya blokir tim dan mendiagnosis masalah. Ketika saya melihat pola berulang diri saya memutuskan untuk menyusun pertanyaan-pertanyaan saya bertanya.
Saya berharap bahwa dengan berbagi teknik saya, orang-orang akan
belajar untuk membuka blokir diri dan mendiagnosa masalah mereka sendiri
desain produk.
Kategori saya memperkenalkan di bawah ini tidak sewenang-wenang. Mereka diambil dari tahun memecahkan masalah nyata. Mereka bukan satu-satunya cara untuk mengiris sesuatu, tetapi mereka adalah cara saya telah digunakan berulang kali dengan sukses. Aku tidak bisa melihat cara untuk merancang tanpa mereka, dan ketika seseorang hilang, sesuatu yang salah. Itulah mengapa saya yakin menyebut mereka penting.
Anda dapat secara luas memisahkan desain produk menjadi dua tahap. Pertama, Anda datang dengan konsep apa yang Anda lakukan, dan kemudian Anda menerapkannya. Konsep Anda datang dengan seperti peta untuk implementasi. Ini memberitahu Anda di mana Anda berada, apa yang sedang Anda kerjakan, dan apa yang tersisa untuk dilakukan. Banyak dari kita menggunakan proses iteratif untuk melaksanakan. Kita belajar melalui proses iterasi dan mengubah rencana awal kami. Saya tidak akan berbicara tentang tahap implementasi. Artikel ini adalah tentang bagaimana Anda mendefinisikan masalah untuk memulai dan bagaimana Anda dapatkan dari sana untuk sebuah konsep.
Tiga tempat untuk mencari masalah
Masalah dengan produk dan desain fitur yang sering melacak kembali ke pendekatan awal. Entah masalahnya tidak didefinisikan dengan baik, konsep itu tidak didefinisikan dengan baik, atau - dalam kasus pemula dan pendatang baru untuk platform - tas Anda trik tidak memadai untuk mengatasi masalah tersebut. Mempertanyakan masing-masing daerah dapat membuka wawasan baru dan membuka blokir Anda.
Aku akan menjelaskan masalah yang Anda menangani sebagai pekerjaan pengguna coba lakukan. Kita akan melihat tas trik Anda bawa ke masalah dalam hal pola yang telah Anda lihat dan diterapkan sebelumnya. Setelah Anda tahu pekerjaan produk Anda yang seharusnya dilakukan, dan Anda memiliki koleksi pola dari pengalaman masa lalu, Anda dapat membuat konsep produk. Konsep ini menyatukan pola yang relevan Anda tahu ke dalam desain komposit yang melakukan pekerjaan.
Job
Saya perlu untuk berhubungan masalah dengan situasi dalam rangka untuk memahaminya. Alasan saya membuat produk adalah untuk memberikan orang kemampuan mereka kekurangan. Itulah sebabnya mereka membayar untuk itu. Kesenjangan antara situasi saat seseorang dan situasi mereka ingin berada di mendefinisikan nilai bagi mereka. Mereka menyewa produk Anda untuk melakukan pekerjaan. Pekerjaan ini definisi mereka tentang kemajuan dari sini ke sana.
Ketika pekerjaan tidak didefinisikan dengan baik, tim tidak tahu apa yang harus dimasukkan dan apa yang harus menghilangkan. Mereka merancang didasarkan pada spekulasi logis, bukan situasi nyata.
Alih-alih menargetkan masalah seperti penembak jitu, mereka melemparkan
jaring dan berharap untuk menangkap nilai di suatu tempat dalam
hamparan nya.
Casting jaring berarti membangun fungsionalitas lebih di lebih banyak
tempat, sehingga proyek tumbuh dalam lingkup dan kompleksitas.
Kadang-kadang orang berpikir bahwa mereka telah menetapkan masalah, tetapi mereka benar-benar hanya didefinisikan fitur. Seperti "pengguna ingin berkas versioning." Sangat penting untuk memahami bahwa fitur ini tidak situasi. Anda dapat menggali ke dalam situasi belajar apa yang berharga dan apa yang tidak sesuai dengan tujuan. Menggali ke dalam definisi fitur tidak melakukan hal itu. Ini tidak memiliki asal-usul dan tidak ada tujuan. Menganalisis definisi fitur membawa Anda untuk bermain keluar semua hal seseorang mungkin nilai dari fitur bukannya belajar apa yang sebenarnya mereka nilai.
Misalkan tim adalah membangun sebuah "versi file" fitur. Dua situasi menentukan nilai berbeda dan mengakibatkan desain yang berbeda.
Dalam satu situasi, seseorang menangkap sebuah kesalahan yang memalukan dalam proposal dan ingin tahu siapa yang harus disalahkan. Untuk melakukan hal ini, mereka perlu untuk melihat informasi tentang versi menengah. Mereka menghargai produk mengatakan kepada mereka yang membuat perubahan apa dan kapan.
Di sisi lain, mempertimbangkan situasi di mana mereka ingin mengirim versi terbaru dari proposal ke klien. Mereka tidak peduli bagaimana itu sampai ke kondisi saat ini. Mereka hanya ingin mengirim file yang benar. Dalam hal ini versi menengah tidak memiliki nilai. Pengguna hanya ingin tahu di mana versi terbaru adalah.
Memutuskan situasi yang Anda merancang untuk memfokuskan masalah. Fokus masalah berfokus tim. Ketika tim tahu di mana nilai tersebut, mereka berhenti berspekulasi tentang semua kasus mungkin dan mereka turun ke bisnis. Lebih mudah untuk membuat keputusan tentang apa yang ada di dan apa yang di luar. Hal ini menyebabkan kriteria jelas yang pola sesuai, pada gilirannya mengarah ke konsep produk yang lebih jelas.
Pola
Setelah Anda telah mengidentifikasi pekerjaan, apa yang memungkinkan Anda untuk melakukan sesuatu tentang hal itu? Perpustakaan Anda dari elemen desain dan teknik memisahkan Anda dari non-profesional. Pola Anda adalah blok bangunan Anda menggabungkan ke dalam konsep produk.
Ketika kita pemula, kami menyalin desain seluruh babi. Itu wajar ketika Anda tidak mengerti bagaimana bagian-bagian individu bekerja dalam isolasi. Anda akan sering melihat pemula template desain mereka setelah aplikasi terkenal seperti Facebook atau Basecamp.
Seperti kita dewasa, kita melihat pola kerja dalam desain kita kagumi. Alih-alih menyalin Facebook seluruh babi, kita menyadari waktu adalah apa yang kita inginkan untuk desain kami. Pola seperti view pengumpulan dan tampilan detail, nav bar, dan proses multi-langkah masuk ke kosakata kita. Pola skala besar ini struktur desain kami.
Ada pola pada skala kecil juga. Dalam aliran komentar, Anda merancang tampilan sebuah komentar individu. Mungkin ada sebuah avatar di sebelah kiri untuk jangkar blok, atau nama tebal di atas. Waktu yang tertera mungkin duduk di bawah header atau mengapung ke kanan di ruang sendiri.
Beberapa orang berpikir pola hal-hal formal yang ditulis dalam sebuah buku atau koleksi, tetapi mereka tidak seperti itu. Mereka seperti bahasa lisan alami dan spontan. Kita belajar bahasa dengan mendengar dan berbicara itu. Kata-kata, frase, dan konstruksi datang ke pikiran seolah-olah dengan sihir. Kami tidak memegang kamus di tangan kami karena kami berbicara dengan orang.
Dengan cara yang sama, kita belajar pola dengan mengekspos diri untuk desain dan merancang diri kita sendiri. Kami menempatkan elemen bersama-sama dan mempelajari apa yang berhasil dan apa yang tidak. Lalu, seperti kata-kata kebiasaan kita datang ke pikiran lebih mudah daripada yang lain, pola yang kita digunakan dengan sukses akan muncul lagi dan lagi dalam menghadapi masalah di masa depan.
Satu hal yang harus diperhatikan dengan pola adalah pola pikir pemula saya sebutkan. Kita kadang-kadang akan menyalin seluruh desain tanpa mengetahui bagaimana mereka bekerja. Hal ini juga terjadi ketika kita bekerja pada platform baru. Sampai kita berbicara bahasa asli, mengatakan iOS, kita akan menemukan lebih mudah untuk mengikuti apa aplikasi lain lakukan dan apa pun yang termudah di API s. Ini proses belajar alami, tetapi kita harus sadar tentang hal itu. Jika konsep produk kami akan dibatasi oleh kosakata kecil kami dan mereka tidak akan menargetkan pekerjaan serta mereka bisa.
Konsep Produk
Ketika kita menerapkan pola kita dengan pekerjaan kita membuat konsep produk. Ini adalah ide seluruh rajutan dari pola yang memecahkan masalah. Ini sering mengambil bentuk beberapa sketsa kunci atau maket yang mendefinisikan proyek.
Berikut ini adalah contoh. Basecamp tumbuh dari konsep yang sangat terfokus.
37signals adalah sebuah perusahaan desain web pada tahun 2003. Satu orang berbicara dengan klien dan lain melakukan desain. Ketika kami menunjukkan bekerja untuk klien, itu adalah permainan telepon bolak-balik. Melakukan desain sederhana tetapi menunjukkan ke klien, lewat umpan balik di sekitar, dan mengirimkan karya baru untuk ditinjau adalah berantakan.
Kami ingin sesuatu untuk membuatnya lebih mudah bagi kita untuk menunjukkan bekerja untuk klien dan mendapatkan umpan balik. Itu pekerjaan.
Blog adalah fenomena baru di tahun 2003. Pola seperti posting, komentar, dan permalinks yang tinggi dalam pikiran kita. Kami juga telah melihat hal-hal seperti dilindungi password halaman web dan interface untuk manajemen user.
Kami menempatkan pola-pola ini bersama-sama ke sebuah konsep produk: blog proyek pribadi di mana Anda bisa posting pekerjaan untuk klien dan mereka bisa mengomentarinya. Itulah jantung Basecamp.
Kadang-kadang tim mulai membangun tanpa konsep produk eksplisit. Sangat mudah untuk melakukan itu ketika Anda berpikir Anda memahami masalah dan Anda yakin dalam keterampilan Anda. Masalahnya adalah bahwa ketika konsep ini tidak eksplisit, proyek menjadi berjalan mabuk. Hal ini menjadi buram dan sulit untuk memperkirakan karena tujuannya tidak jelas.
Sebuah konsep produk memberikan peta wilayah Anda mencoba untuk menutupi selama pelaksanaan. Melihat peta yang menunjukkan area mana Anda tertutup dan mana yang belum Anda. Ini membantu Anda menjawab "Apakah kita sudah sampai?" Dengan lebih presisi.
Berhati-hatilah ketika orang-orang teknis pada sebuah proyek mulai menerapkan tanpa antarmuka eksplisit atau end-point dalam pikiran. Pengembangan produk yang baik adalah urutan taruhan. Anda bertaruh pada konsep, menerapkannya, dan mengujinya dalam konteks. Apakah itu melakukan pekerjaan itu? Apa yang berhasil dan apa yang tidak?
Tujuan dari proses desain adalah untuk mencapai kebugaran antara masalah dan solusi. Pekerjaan mendefinisikan masalah dan konsep Anda mendefinisikan solusi. Saat kebenaran yang terjadi ketika Anda cocok dua bersama-sama. Saat itulah Anda menguji taruhan Anda.
Jika Anda tidak eksplisit tentang bagaimana Anda mendefinisikan masalah versus bagaimana Anda membangun solusi, Anda akan tersesat dalam perdebatan ketika hal-hal yang tidak benar. Satu orang akan berbicara tentang masalah sementara yang lain mempertanyakan solusi, namun orang lain menunjukkan rincian dari eksekusi. Fokus pada satu aspek pada satu waktu untuk membuat perdebatan produktif.
Umum dan Rekursif
Jika Anda mengambil waktu untuk mempertimbangkan tiga unsur, Anda akan menemukan mereka berlaku di banyak skala proyek. Sebuah produk memiliki pekerjaan secara keseluruhan dan konsep. Setiap fitur memiliki pekerjaan dan konsep. Hal yang sama berlaku untuk metode individual dalam kode. Dan ada pola di semua tingkatan, dari struktur skala besar untuk elemen desain individu untuk pilihan kode.
Sifat umum dari elemen-elemen ini membuat mereka kuat. Artikel ini sendiri dirancang untuk pekerjaan (masalah debug dalam desain produk), menggunakan pola konstruksi (ilustrasi, header dan paragraf), dan mengikuti konsep keseluruhan (tiga unsur sebagai suatu sistem dan satu-per-satu penjelasan mereka) .
Bila Anda tidak harus menggunakan ini
Karena artikel ini adalah produk itu sendiri, ada situasi di mana itu berharga dan orang-orang di mana tidak. Ini berlaku ketika Anda sedang berjuang untuk mencapai tujuan tertentu. Definisi masalah dan definisi konsep membantu kita sejauh kita berusaha untuk mendapatkan suatu tempat pada khususnya.
Ini bekerja melawan Anda ketika pekerjaan Anda tidak diarahkan pada tujuan. R & D dan desain proyek eksplorasi tidak mendapatkan manfaat dari definisi masalah yang sempit. Platform dan proyek infrastruktur yang berbeda dalam jenis dari proyek produk karena platform ini dimaksudkan untuk memungkinkan produk di atasnya, yang dengan sendirinya ditargetkan pada situasi tertentu.
Semakin Anda mencoba untuk memberikan kemampuan khusus untuk situasi tertentu, semakin vital unsur-unsur - pekerjaan, pola dan konsep produk Anda - membawa Anda ke sana.
Kategori saya memperkenalkan di bawah ini tidak sewenang-wenang. Mereka diambil dari tahun memecahkan masalah nyata. Mereka bukan satu-satunya cara untuk mengiris sesuatu, tetapi mereka adalah cara saya telah digunakan berulang kali dengan sukses. Aku tidak bisa melihat cara untuk merancang tanpa mereka, dan ketika seseorang hilang, sesuatu yang salah. Itulah mengapa saya yakin menyebut mereka penting.
Anda dapat secara luas memisahkan desain produk menjadi dua tahap. Pertama, Anda datang dengan konsep apa yang Anda lakukan, dan kemudian Anda menerapkannya. Konsep Anda datang dengan seperti peta untuk implementasi. Ini memberitahu Anda di mana Anda berada, apa yang sedang Anda kerjakan, dan apa yang tersisa untuk dilakukan. Banyak dari kita menggunakan proses iteratif untuk melaksanakan. Kita belajar melalui proses iterasi dan mengubah rencana awal kami. Saya tidak akan berbicara tentang tahap implementasi. Artikel ini adalah tentang bagaimana Anda mendefinisikan masalah untuk memulai dan bagaimana Anda dapatkan dari sana untuk sebuah konsep.
Tiga tempat untuk mencari masalah
Masalah dengan produk dan desain fitur yang sering melacak kembali ke pendekatan awal. Entah masalahnya tidak didefinisikan dengan baik, konsep itu tidak didefinisikan dengan baik, atau - dalam kasus pemula dan pendatang baru untuk platform - tas Anda trik tidak memadai untuk mengatasi masalah tersebut. Mempertanyakan masing-masing daerah dapat membuka wawasan baru dan membuka blokir Anda.
Aku akan menjelaskan masalah yang Anda menangani sebagai pekerjaan pengguna coba lakukan. Kita akan melihat tas trik Anda bawa ke masalah dalam hal pola yang telah Anda lihat dan diterapkan sebelumnya. Setelah Anda tahu pekerjaan produk Anda yang seharusnya dilakukan, dan Anda memiliki koleksi pola dari pengalaman masa lalu, Anda dapat membuat konsep produk. Konsep ini menyatukan pola yang relevan Anda tahu ke dalam desain komposit yang melakukan pekerjaan.
Saya perlu untuk berhubungan masalah dengan situasi dalam rangka untuk memahaminya. Alasan saya membuat produk adalah untuk memberikan orang kemampuan mereka kekurangan. Itulah sebabnya mereka membayar untuk itu. Kesenjangan antara situasi saat seseorang dan situasi mereka ingin berada di mendefinisikan nilai bagi mereka. Mereka menyewa produk Anda untuk melakukan pekerjaan. Pekerjaan ini definisi mereka tentang kemajuan dari sini ke sana.
Kadang-kadang orang berpikir bahwa mereka telah menetapkan masalah, tetapi mereka benar-benar hanya didefinisikan fitur. Seperti "pengguna ingin berkas versioning." Sangat penting untuk memahami bahwa fitur ini tidak situasi. Anda dapat menggali ke dalam situasi belajar apa yang berharga dan apa yang tidak sesuai dengan tujuan. Menggali ke dalam definisi fitur tidak melakukan hal itu. Ini tidak memiliki asal-usul dan tidak ada tujuan. Menganalisis definisi fitur membawa Anda untuk bermain keluar semua hal seseorang mungkin nilai dari fitur bukannya belajar apa yang sebenarnya mereka nilai.
Misalkan tim adalah membangun sebuah "versi file" fitur. Dua situasi menentukan nilai berbeda dan mengakibatkan desain yang berbeda.
Dalam satu situasi, seseorang menangkap sebuah kesalahan yang memalukan dalam proposal dan ingin tahu siapa yang harus disalahkan. Untuk melakukan hal ini, mereka perlu untuk melihat informasi tentang versi menengah. Mereka menghargai produk mengatakan kepada mereka yang membuat perubahan apa dan kapan.
Di sisi lain, mempertimbangkan situasi di mana mereka ingin mengirim versi terbaru dari proposal ke klien. Mereka tidak peduli bagaimana itu sampai ke kondisi saat ini. Mereka hanya ingin mengirim file yang benar. Dalam hal ini versi menengah tidak memiliki nilai. Pengguna hanya ingin tahu di mana versi terbaru adalah.
Memutuskan situasi yang Anda merancang untuk memfokuskan masalah. Fokus masalah berfokus tim. Ketika tim tahu di mana nilai tersebut, mereka berhenti berspekulasi tentang semua kasus mungkin dan mereka turun ke bisnis. Lebih mudah untuk membuat keputusan tentang apa yang ada di dan apa yang di luar. Hal ini menyebabkan kriteria jelas yang pola sesuai, pada gilirannya mengarah ke konsep produk yang lebih jelas.
Pola
Setelah Anda telah mengidentifikasi pekerjaan, apa yang memungkinkan Anda untuk melakukan sesuatu tentang hal itu? Perpustakaan Anda dari elemen desain dan teknik memisahkan Anda dari non-profesional. Pola Anda adalah blok bangunan Anda menggabungkan ke dalam konsep produk.
Ketika kita pemula, kami menyalin desain seluruh babi. Itu wajar ketika Anda tidak mengerti bagaimana bagian-bagian individu bekerja dalam isolasi. Anda akan sering melihat pemula template desain mereka setelah aplikasi terkenal seperti Facebook atau Basecamp.
Seperti kita dewasa, kita melihat pola kerja dalam desain kita kagumi. Alih-alih menyalin Facebook seluruh babi, kita menyadari waktu adalah apa yang kita inginkan untuk desain kami. Pola seperti view pengumpulan dan tampilan detail, nav bar, dan proses multi-langkah masuk ke kosakata kita. Pola skala besar ini struktur desain kami.
Ada pola pada skala kecil juga. Dalam aliran komentar, Anda merancang tampilan sebuah komentar individu. Mungkin ada sebuah avatar di sebelah kiri untuk jangkar blok, atau nama tebal di atas. Waktu yang tertera mungkin duduk di bawah header atau mengapung ke kanan di ruang sendiri.
Beberapa orang berpikir pola hal-hal formal yang ditulis dalam sebuah buku atau koleksi, tetapi mereka tidak seperti itu. Mereka seperti bahasa lisan alami dan spontan. Kita belajar bahasa dengan mendengar dan berbicara itu. Kata-kata, frase, dan konstruksi datang ke pikiran seolah-olah dengan sihir. Kami tidak memegang kamus di tangan kami karena kami berbicara dengan orang.
Dengan cara yang sama, kita belajar pola dengan mengekspos diri untuk desain dan merancang diri kita sendiri. Kami menempatkan elemen bersama-sama dan mempelajari apa yang berhasil dan apa yang tidak. Lalu, seperti kata-kata kebiasaan kita datang ke pikiran lebih mudah daripada yang lain, pola yang kita digunakan dengan sukses akan muncul lagi dan lagi dalam menghadapi masalah di masa depan.
Satu hal yang harus diperhatikan dengan pola adalah pola pikir pemula saya sebutkan. Kita kadang-kadang akan menyalin seluruh desain tanpa mengetahui bagaimana mereka bekerja. Hal ini juga terjadi ketika kita bekerja pada platform baru. Sampai kita berbicara bahasa asli, mengatakan iOS, kita akan menemukan lebih mudah untuk mengikuti apa aplikasi lain lakukan dan apa pun yang termudah di API s. Ini proses belajar alami, tetapi kita harus sadar tentang hal itu. Jika konsep produk kami akan dibatasi oleh kosakata kecil kami dan mereka tidak akan menargetkan pekerjaan serta mereka bisa.
Konsep Produk
Ketika kita menerapkan pola kita dengan pekerjaan kita membuat konsep produk. Ini adalah ide seluruh rajutan dari pola yang memecahkan masalah. Ini sering mengambil bentuk beberapa sketsa kunci atau maket yang mendefinisikan proyek.
Berikut ini adalah contoh. Basecamp tumbuh dari konsep yang sangat terfokus.
37signals adalah sebuah perusahaan desain web pada tahun 2003. Satu orang berbicara dengan klien dan lain melakukan desain. Ketika kami menunjukkan bekerja untuk klien, itu adalah permainan telepon bolak-balik. Melakukan desain sederhana tetapi menunjukkan ke klien, lewat umpan balik di sekitar, dan mengirimkan karya baru untuk ditinjau adalah berantakan.
Kami ingin sesuatu untuk membuatnya lebih mudah bagi kita untuk menunjukkan bekerja untuk klien dan mendapatkan umpan balik. Itu pekerjaan.
Blog adalah fenomena baru di tahun 2003. Pola seperti posting, komentar, dan permalinks yang tinggi dalam pikiran kita. Kami juga telah melihat hal-hal seperti dilindungi password halaman web dan interface untuk manajemen user.
Kami menempatkan pola-pola ini bersama-sama ke sebuah konsep produk: blog proyek pribadi di mana Anda bisa posting pekerjaan untuk klien dan mereka bisa mengomentarinya. Itulah jantung Basecamp.
Sebuah konsep produk memberikan peta wilayah Anda mencoba untuk menutupi selama pelaksanaan. Melihat peta yang menunjukkan area mana Anda tertutup dan mana yang belum Anda. Ini membantu Anda menjawab "Apakah kita sudah sampai?" Dengan lebih presisi.
Berhati-hatilah ketika orang-orang teknis pada sebuah proyek mulai menerapkan tanpa antarmuka eksplisit atau end-point dalam pikiran. Pengembangan produk yang baik adalah urutan taruhan. Anda bertaruh pada konsep, menerapkannya, dan mengujinya dalam konteks. Apakah itu melakukan pekerjaan itu? Apa yang berhasil dan apa yang tidak?
Tujuan dari proses desain adalah untuk mencapai kebugaran antara masalah dan solusi. Pekerjaan mendefinisikan masalah dan konsep Anda mendefinisikan solusi. Saat kebenaran yang terjadi ketika Anda cocok dua bersama-sama. Saat itulah Anda menguji taruhan Anda.
Jika Anda tidak eksplisit tentang bagaimana Anda mendefinisikan masalah versus bagaimana Anda membangun solusi, Anda akan tersesat dalam perdebatan ketika hal-hal yang tidak benar. Satu orang akan berbicara tentang masalah sementara yang lain mempertanyakan solusi, namun orang lain menunjukkan rincian dari eksekusi. Fokus pada satu aspek pada satu waktu untuk membuat perdebatan produktif.
Umum dan Rekursif
Jika Anda mengambil waktu untuk mempertimbangkan tiga unsur, Anda akan menemukan mereka berlaku di banyak skala proyek. Sebuah produk memiliki pekerjaan secara keseluruhan dan konsep. Setiap fitur memiliki pekerjaan dan konsep. Hal yang sama berlaku untuk metode individual dalam kode. Dan ada pola di semua tingkatan, dari struktur skala besar untuk elemen desain individu untuk pilihan kode.
Sifat umum dari elemen-elemen ini membuat mereka kuat. Artikel ini sendiri dirancang untuk pekerjaan (masalah debug dalam desain produk), menggunakan pola konstruksi (ilustrasi, header dan paragraf), dan mengikuti konsep keseluruhan (tiga unsur sebagai suatu sistem dan satu-per-satu penjelasan mereka) .
Bila Anda tidak harus menggunakan ini
Karena artikel ini adalah produk itu sendiri, ada situasi di mana itu berharga dan orang-orang di mana tidak. Ini berlaku ketika Anda sedang berjuang untuk mencapai tujuan tertentu. Definisi masalah dan definisi konsep membantu kita sejauh kita berusaha untuk mendapatkan suatu tempat pada khususnya.
Ini bekerja melawan Anda ketika pekerjaan Anda tidak diarahkan pada tujuan. R & D dan desain proyek eksplorasi tidak mendapatkan manfaat dari definisi masalah yang sempit. Platform dan proyek infrastruktur yang berbeda dalam jenis dari proyek produk karena platform ini dimaksudkan untuk memungkinkan produk di atasnya, yang dengan sendirinya ditargetkan pada situasi tertentu.
Semakin Anda mencoba untuk memberikan kemampuan khusus untuk situasi tertentu, semakin vital unsur-unsur - pekerjaan, pola dan konsep produk Anda - membawa Anda ke sana.
Tidak ada komentar:
Posting Komentar