Saya kebetulan membuat divisi desain dari awal di Alfa-Bank dan bekerja sebagai direktur desain. Butuh lima tahun. Akibatnya, kami mendapat sistem desain (dalam kode) dan pendekatan desain produk digital. Sebenarnya, saya akan berbicara tentang pendekatan ini di sini. Lebih tepatnya, ini adalah teks dari kuliah yang saya berikan pada awal 2018 di Moskow, Perm, Novosibirsk dan St. Petersburg. Pada bulan Mei, saya memutuskan untuk meninggalkan bank, sekarang saya berkeliling untuk menerbitkan teks ceramah.
Di Alpha Lab, kami membangun proses pengembangan produk sesuai dengan scrum, di mana masing-masing tim adalah unit independen yang mampu memberikan secepat yang mereka bisa (idealnya, sprint mingguan atau dua minggu).
Penafian penting: seluruh teks bercerita tentang pekerjaan perancang dalam tim scrum. Ini adalah peringatan yang sangat penting untuk diingat. Dalam ceramah, saya menyebutkan hal ini secara sepintas, sebagai hal yang biasa, sehingga seseorang dapat kehilangan makna cerita. Untuk pendekatan kanban dan tradisional (kontrak-desain-tata letak-perakitan-tindakan), metode ini bahkan mungkin membahayakan. Karena itu, jika konsep "scrum" baru bagi Anda, pelajari pendekatannya - mungkin itu akan membantu seseorang mengatur pekerjaan mereka dengan lebih baik. Dalam perjalanan teks, saya menuangkan tautan ke artikel dan buku.
Pada akhir 2017, ada sekitar 30 tim di Laboratorium (mungkin lebih), dan hampir semua orang membutuhkan desainer mereka sendiri. Bahkan pada skala yang relatif besar, lebih penting untuk bekerja di level strategi, konsep dan pendekatan tingkat atas, oleh karena itu tidak mungkin untuk "secara teknis" mengelola pekerjaan 30 desainer yang bekerja pada produk yang berbeda dan dalam tim yang berbeda dan pada kecepatan yang berbeda. Taktik ditentukan oleh masing-masing tim secara independen, dalam pesona semua ini.
1. Tujuan: Produk kerja yang digunakan orang
Sungguh tujuan yang sederhana. Kami akan menganalisis setiap kata, karena tidak hanya dirumuskan dengan kata-kata ini.
Perhatikan kurangnya kata-kata proses, seperti "kreasi", "desain" dan sebagainya. Proses bukanlah tujuan sama sekali. Tujuannya hanya bisa berupa hasil, bukan proses. Tetapi desainer di seluruh dunia jatuh ke dalam perangkap mental proses, sehingga hasil pekerjaan mereka adalah artefak proses, bukan produk yang berfungsi.
Saya memiliki statistik yang menyedihkan. Dari sepuluh desainer yang datang untuk “membuat produk dan mempengaruhinya”, satu berfokus pada hasilnya, sisanya berfokus pada proses. Itu datang lama, dan yah, jika itu datang sama sekali.
Sebelum kemarahan itu datang, saya akan mengklarifikasi: Saya tidak mengurangi pentingnya proses dan memahaminya. Kerangka kerja, penelitian, desain, metodologi, spesifikasi, pedoman, sistem desain, perangkat lunak profesional dan sebagainya. Segera setelah produk jatuh ke tangan pengguna, semua ini tidak masuk akal: produknya berfungsi atau tidak.
Penjelasan yang membosankan tentang proses dan kebencianJika pengguna mengunduh aplikasi dan itu tidak bekerja atau tidak menyelesaikan tugasnya, semuanya menjadi tidak penting: bagaimana data dikumpulkan dan diteliti, tata letak apa, dalam perangkat lunak apa mereka dijalankan, apa diagram alur dan kotak abu-abu, bagaimana programmer bekerja dengan putus asa sebelum peluncuran dan apa itu video keren keluar dari pesta untuk menghormati peluncuran produk.
Pengaya profesional apa pun untuk "mempercepat" atau "meningkatkan" proses seringkali hanya secara sederhana (sudah menjadi tambahan, yaitu, faktanya fenomena yang berlebihan) menambah proses dan birokrasi, tidak menyelesaikan masalah dan tidak memindahkan tim ke tujuan, tetapi memindahkannya dari itu. Ambil prototyping 1 yang sama: alih-alih pengembangan, kami membuat emulator yang memberikan kekuatan 10-30% dari pengalaman yang akan ada dalam produk. Dan desain. Dan penelitian. Dan tata letak. Dan bingkai gambar SEBELUM tata letak (beberapa membedakan tahap ini dari desain dan menempatkan makna yang berbeda dalam istilah yang sama). Lalu deskripsi panduannya. Dan juga "pengawasan penulis" (nama yang sangat vulgar untuk mengintip karya pengembang dan dengusan - di sini satu miliar yang tidak terhitung dalam semua "studi" dan nuansa "prototipe" ini terungkap). Jadi, alih-alih berjuang untuk hasil dalam bentuk produk, desainer atau manajer menciptakan banyak keributan berbiaya tinggi. Profesi yang terpisah seperti "perancang", "perancang antarmuka", "perancang UX / UI", "periset" dan sebagainya terus berkembang. Di konferensi, mereka dengan serius mulai membahas legitimasi untuk menempelkan UX dan UI, mengatakan bahwa orang yang berbeda harus melakukan ini, alat dan tugas yang berbeda. Alih-alih berfokus pada produk yang berfungsi, kami mendapatkan fokus pada proses, dan setiap tambahan hanya bergerak menjauh dari tujuan sebenarnya.
Anda perlu memahami bahwa di sini kita hanya berbicara tentang proses yang paling erat kaitannya dengan pekerjaan orang yang kita sebut desainer (tidak peduli siapa yang menempatkan konsep kolektif ini). Proses yang sudah mapan dalam perusahaan lama, yang disebut "proses bisnis", dan yang seringkali paling kuat mempengaruhi pengalaman produk dan pengguna, tidak dapat dipertanyakan lagi.
Pokoknya, kembali ke kata-katanya.
- Produk yang berfungsi adalah produk yang dapat digunakan untuk memecahkan masalah. Ini tentang kemampuan teknis untuk memecahkan masalah menggunakan produk.
- Produk ini adalah jenis entitas lengkap, utuh, dalam jumlah bahan yang memiliki nilai lebih dari semuanya diambil secara terpisah.
- Gunakan - berbicara tentang permintaan dan kenyamanan.
- Orang-orang adalah konsep yang lebih luas daripada "pelanggan", "pengguna", "karyawan", dll. Ketika bekerja untuk orang-orang, kami mempertimbangkan ergonomi dan beberapa standar.
Katakanlah produknya tidak berfungsi. Semuanya jelas di sini: mereka tidak akan digunakan (setidaknya untuk tujuan yang dimaksudkan).
Atau bukan produk: seperangkat komponen yang berbeda yang tidak saling terhubung oleh tanda apa pun (ini juga terjadi).
Atau ada produk, tetapi mereka tidak menggunakannya (sama sekali). Juga sebuah kegagalan, bisa jadi siapa saja: kurangnya pemasaran, tidak nyaman, melambat.
Jika tidak orang menggunakannya ... maka, saya akui, akan ada prinsip desain yang sama sekali berbeda.
Ide ini dibahas dari sudut yang berbeda ketika mereka berbicara tentang Agile, dan tentang pengiriman yang sering, dan tentang Scrum, dan tentang kerja tim, tetapi bahkan dengan praktik seperti itu, desainer kadang-kadang kadang-kadang masuk ke dalam alur "proses" yang nyaman. Saya akui alasan tersebut:
- Mereka tidak memahami teknologi dan pengaruhnya terhadap mereka,
- tidak dapat memengaruhi hasilnya (takut "mereka tidak mendengarkan", kurang motivasi, menciptakan subordinasi "mereka tidak menyuruh saya melakukan ini")
- tidak mengerti peran mereka
- scrum dieksploitasi tanpa memahami tujuannya, seperti kerangka kerja (lihat juga Cult of Cargo ) - maka itu pasti tidak lebih baik daripada air terjun (atau bahkan lebih buruk)
- mengatur air terjun kecil di dalam scrum :-) - “Pertama, desain, lalu front-end”, daripada bekerja setidaknya dua / dua. Ini, untuk beberapa alasan, sangat sulit bagi para desainer dan pengembang (tetapi ketika dan jika ya, maka mereka tidak lagi ingin kembali ke model air-air mini, karena cacat dalam segala hal).
PS Tautan ke deskripsi metodologi yang terdaftar, Wikipedia:
2. Peran desainer dalam tim scrum
Seringkali peran seorang desainer dalam tim produk dilebih-lebihkan karena mereka berpikir dalam hal proses dan urutan tindakan (air terjun) alih-alih hasilnya.
(Untuk berpikir dengan benar dari hasil, berdasarkan kategori tujuan.)
Pengembang, yang baru saja melakukan segalanya sesuai dengan standar dan spesifikasi, kemungkinan besar akan menyelesaikan masalah dengan lebih baik daripada jika ia melalui mock-up desainer. Mungkin bahkan metrik belanjaan akan lebih baik. Dengan tidak adanya seorang desainer.
“Kami menunggu tata letak” - jika itu terdengar, maka proses dalam tim tidak diatur dengan benar.
(Sayangnya, banyak pengembang dan desainer tidak menyadari standar - setidaknya W3C untuk web, dan ada banyak prinsip dasar yang membantu membangun pengalaman yang lebih baik. Secara analogi, ada deskripsi / standar untuk platform seluler dan desktop terkemuka; iOS , Material .)
Perhatikan startup - Facebook, Vkontakte, Odnoklassniki dan Apple dengan Microsoft: mereka didasarkan pada solusi teknik (Wozniak, Gates), yang kemudian disatukan oleh desainer. Mereka menciptakan produk sesuai dengan Tujuannya.
Pertama adalah produk yang berfungsi.
(Tampan, demi keadilan, para lelaki ideologis di laboratorium Xerox melakukannya, tetapi skala konsekuensinya sama sekali berbeda.)
•••
Lalu apa peran desainer?
Untuk menambah nilai .
Anda dapat menambah sesuatu yang ada , perhatikan.
Nilai di mata pelanggan, pengguna.
•••
Seringkali urutan terbalik dan "menunggu desain". Ini, tentu saja, berbicara tentang ketidakdewasaan tim dan manajemen yang tidak memadai dari tim ini.
•••
"Layouts" adalah anakronisme, warisan dari web statis yang digunakan untuk mengikuti estetika dan proses pembuatan majalah dan grafik surat kabar. Dalam desain produk, ini tidak lagi relevan, tetapi pendekatan - tanpa adanya yang lain - tetap ada, baik dalam proses maupun dalam kesadaran.
Mulai dengan kode alih-alih tata letak.
Aplikasi - dinamika, gerakan, interaksi. Oleh karena itu, tata letak dalam karya perancang produk sering tidak sesuai dan bertentangan dengan tujuan.
Itulah sebabnya desainer maju bermigrasi ke prototipe dengan data nyata. Apakah ini bagus? Saya pikir ini berlebihan - mengapa memprogram prototipe ketika Anda dapat (dan secara logis) segera memprogram suatu produk?
Lebih baik segera beralih dari pengembangan ke desain. Mulai dengan kode - prototipe yang melakukan tugas klien dengan cara minimal. Prototipe yang dapat digunakan untuk pasokan kerja (ingat nanti tentang Pengembangan Pelanggan).
(Keterbukaan dan kematangan pengembang penting di sini - kesediaan mereka untuk bereksperimen dan meningkatkan program, bahkan mungkin menulis ulang kode beberapa kali lagi. Saya yakin ada banyak solusi yang sudah jadi untuk ini untuk waktu yang lama.)
Penyimpangan liris: contoh dari dunia fisikDibandingkan dengan kertas, hal fisik sangat menarik, karena sejauh ini lebih jelas daripada yang lain. Karena itu, saya akan menyerah pada godaan dan memberikan analogi dari kehidupan seorang desainer grafis.
Bayangkan bahwa produk yang berfungsi adalah konten publikasi (buku, majalah, koran). Penting untuk mengemasnya dengan benar dan menyampaikannya kepada pembaca. Tanpa konten, tidak ada artinya dalam desain. Buku kosong tidak memuaskan pembaca. Peran pengembang, bandingkan peran penulis. Dan tanpa desain yang bagus, isi buku masih berharga.
Dan konten dapat didistribusikan lebih lanjut sesuka Anda. By the way, sekarang konten didistribusikan di antara massa media - dari kertas ke elektronik. Buku-buku yang sama dalam bentuk elektronik hidup dalam berbagai format dan pembaca, mengukuhkan prioritas konten daripada desain.
(Berbicara tentang sistem desain: ini adalah solusi gaya untuk desain konten cepat. Alat pengembangan, bukan alat desain.)
Takeaway
Sadarilah tugas pengguna.
Mulailah dengan mengembangkan. Bekerjasama dengan pengembang (sebagai art director dan copywriter).
Tingkatkan produk yang berfungsi sebagai ganti tata letak.
Pikirkan dalam hal tujuan, hasil daripada proses.
Perancang produk menciptakan produk, bukan tata letak.
3. Metode
Metode ini, bersama-sama dengan perpustakaan komponen, telah menjadi dasar dari sistem desain perbankan .
Saya mengusulkan untuk bekerja dalam urutan berikut:
- Kenali tugas klien (pengguna) dan komit sebagai Kisah Pengguna.
- Tentukan metrik. Bagaimana kami memahami bahwa tugas pengguna telah diselesaikan? Berkomitmen.
- Merumuskan hipotesis. Berkomitmen.
- Peta Perjalanan Pelanggan.
- Prototipe yang berfungsi. MVP Pengembangan Pelanggan.
Tata letak. (Dengan kerja tim dan sistem desain yang ada, Anda dapat melakukannya tanpa tata letak).
Tugas pelanggan
Segalanya tampak jelas di sini, tetapi seringkali tidak. Hipotesis antarmuka bingung dengan tugas-tugas klien, mereka diberikan oleh Wishlist Wishlist dan umumnya digunakan untuk manipulasi tim yang tidak begitu cantik.
Tugas klien diidentifikasi baik berdasarkan keluhan ("nyeri pelanggan") atau kebutuhan penelitian.
(Secara sepintas, kami mencatat bahwa keluhan dan tugas adalah dua hal yang berbeda, dan penting untuk tetap tenang dan tidak terburu-buru untuk "memecahkan masalah" berdasarkan keluhan - tugas mungkin berbeda, dan keluhan tersebut disebabkan oleh keadaan yang tidak terkait. Dilengkapi dengan pengalaman. Gunakan metode "lima alasan" - kadang-kadang membantu untuk sampai ke dasar dasar di mana tugas objektif dapat dirumuskan.)
Ketika tugas direalisasikan, itu direkam sebagai Kisah Pengguna. Banyak artikel dan buku telah ditulis tentang ini, jadi saya tidak akan mengulangi lagi di sini - belajarlah sendiri.
Untuk wawasan tentang masalah ini, saya sangat merekomendasikan buku Pemetaan Cerita Pengguna: Temukan Kisah Utuh, Bangun Produk yang Tepat (Jeff Patton dan Peter Economy) .
Dua jenis metrik (penting untuk memperbaiki keduanya!)
- Jawaban yang dirumuskan untuk pertanyaan "Bagaimana kita memahami bahwa tugas pengguna telah diselesaikan." Apa yang ingin kita dapatkan dalam bentuk solusi.
- Digital: nilai relatif dan absolut. Lebih sering tentang indikator kuantitatif (keuangan, kecepatan, pelanggan, waktu). Bagaimana kita memahami bahwa keputusan itu berhasil. Ada trik: sering dalam presentasi, nilai-nilai relatif disembunyikan, dilebih-lebihkan, atau kehilangan skala objektif keputusan. Misalnya, "pertumbuhan pemirsa adalah 3%" - apakah banyak atau sedikit? Jika 150.000 orang (permukiman tipe perkotaan, dengan sekolah dan taman kanak-kanak, toko-toko dan administrasi sendiri), maka ini sudah merupakan jumlah yang mengesankan, meskipun sepertinya hal-hal kecil. Di sisi lain, "pertumbuhan laba 300%", jika 300 rubel per bulan, sudah merupakan indikator yang meragukan. Dan lagi, jika 150.000 orang adalah kesalahan statistik dalam ukuran pemirsa seluruh produk (misalnya, mengunjungi halaman utama mesin pencari per tahun), maka ukuran ini kemungkinan besar dapat diabaikan, meskipun kita berbicara tentang populasi desa tipe perkotaan yang sama.
Sering kali ternyata metrik muncul setelah produk atau fitur telah dilakukan. Untuk pelaporan dan presentasi yang indah. Ini menyedihkan dan tidak menunjukkan keterampilan, tetapi, sebaliknya, merusak gambar dan menciptakan rasa tenang yang salah (perhitungan selalu terjadi). Situasi diilustrasikan dengan sangat baik oleh lelucon tentang pemanah terbaik di dunia.
Lelucon tentang pemanahPemanah terbaik di dunia
Alkisah ada pemanah terbaik di dunia. Katakanlah itu di Jepang - demi plot. Dia bisa mengenai target lebih baik daripada siapa pun dari jarak terjauh, dan bahkan bagaimana Robin Hood bisa mengenai panahnya sendiri. Archer melakukan perjalanan keliling negeri dan mengejutkan orang lain dengan keahliannya, berbagi pengalamannya.
Di satu desa, ia menemukan banyak target yang mencengangkan, dan mereka berada di tempat yang paling tak terduga dan tidak dapat diakses. Sang pemanah menyadari bahwa sang Guru tinggal di sini, tingkat penguasaan yang tidak pernah bisa dia capai.
Pemanah menyadari bahwa misinya telah selesai dan tidak ada gunanya hidup terus. Dia sedang bersiap untuk melakukan ritual bunuh diri - sepukka - ketika seorang petani melewatinya.
"Apa yang terjadi, Archer?" - petani terkejut.
"Saya telah menemukan bahwa seorang Guru Besar tinggal di permukiman Anda, yang jauh lebih unggul dari saya dalam keterampilan, oleh karena itu misi saya selesai dan saya dapat meninggalkan dunia ini."
"Kamu mungkin berbicara tentang target yang paling aneh di tempat paling aneh?" - Tiba-tiba menebak petani.
"Oh ya, kamu benar," kata Archer dengan menyesal.
- Oh Archer! Ketahui: ini adalah trik orang bodoh setempat. Dia menembakkan panah secara acak, dan menggambar di sekitar target nanti. Kita semua mengasihani dia. Anda salah.
Hipotesis - jawaban atas pertanyaan tentang cara tercepat untuk menyelesaikan masalah pengguna
Selalu ada beberapa solusi untuk masalah ini. Dalam pengembangan (desain) tidak bisa dibatasi hanya satu! Tidak ada yang tahu sebelumnya mana yang akan bekerja paling baik.
Lakukan pekerjaan mental dan berikan paling tidak tiga solusi berbeda.
Ingatlah bahwa "mengembangkan" satu ide dalam bentuk tata letak yang berubah secara progresif adalah satu solusi, bukan tiga (atau berapa banyak tata letak berbeda yang berhasil Anda buat).
Untuk kesederhanaan, coba tiga pendekatan:
- Solusi antarmuka. Mungkin juga ada beberapa.
- Otomatis (misalnya, tugas dilakukan di server setelah terjadinya suatu peristiwa) - tanpa campur tangan pengguna.
- Proses - apa yang dapat diubah dalam proses sehingga pengguna tidak menemukan tugas sama sekali, tetapi menerima solusi pada waktu yang tepat.
Solusi terbaik ditemukan secara eksklusif dalam cara empiris (lihat “Metode Ilmiah”). Solusi / ide sekilas apa pun yang paling liar pun harus diperiksa. Hipotesis perlu diperiksa. Kasus ideal adalah untuk menguji ketiga hipotesis yang dilakukan dalam bentuk MVP. Anda akan membuat prototipe untuk ini.
Peta Perjalanan Pelanggan Terjun Ke Dalam Konteks
Jika Anda memiliki produk kecil dengan fungsi tunggal, maka CJM memungkinkan Anda untuk melihat seluruh proses penyelesaian masalah oleh pengguna dan mengidentifikasi titik-titik rasa sakit, menyadari penyelesaian tugas yang sebenarnya.
Jika tugasnya adalah untuk mengembangkan fitur dalam aplikasi yang ada, maka CJM membenamkan dalam konteks dan memberikan solusi yang mulus dan mulus untuk masalah tersebut. Seringkali, mengabaikan konteks, desainer dan manajer produk membuat "bagian baru", memperbanyak entitas, mempersulit navigasi dan menciptakan kebingungan di antarmuka.
Cukup banyak yang telah ditulis tentang CJM, Anda perlu mempelajarinya sendiri dan menerapkannya dalam pekerjaan Anda.
Anda bisa mulai dengan buku " Cerita Kustom " oleh Jeff Patton.
Prototipe yang berfungsi. MVP Pengembangan Pelanggan.
Atur dengan pengembang dan buat prototipe yang berfungsi untuk menguji setiap hipotesis. Ini tidak akan menjadi solusi ideal baik secara teknis maupun estetika - penting untuk membuat produk yang layak secara minimum ( MVP ), di mana pengujian Anda dapat melibatkan pelanggan baru dan yang sudah ada (Pengembangan Pelanggan).
« . Lean Startup -» . .
MVP, . .
,
Selama pengembangan MVP dan pengujian prototipe, Anda pasti akan memperbaiki banyak hal kecil dalam setiap pengiriman dan setelah setiap sesi umpan balik pengguna. Maksimum yang harus dilakukan adalah menyelaraskan layar solusi siap pakai dalam gaya dan pengujian ulang. Tampilan yang segar pada produk dapat menyarankan solusi baru, menyederhanakan sesuatu yang lebih dan memikirkan kembali, membuat hasilnya lebih nyaman dan lebih cantik bagi pengguna - ini adalah tempat nilai tambah muncul.
Takeaway
Kisah PenggunaBagaimana menentukan keberhasilanHipotesis (solusi)CJMPrototype, MVP,Tata Letak Pengembangan Pelanggan ( jika diperlukan)Untuk informasi
Hal terbesar yang dapat Anda lakukan
, / , . , .
.
, - , . , , . -. : , - , . , , , .
: , , . . , , .
, . ( ), , , , . , ( , «»; — ).
: , . , . — -: , — . -, . , , , , . ( «»), /. / , : / , , .
, .
, .
?
, / (), , , , . . , , .
, .
: ?
? ?
?
30 ? ?
? , ?
?
, ?
— , . .
, . — , : , . .
.
« », .
, . , . . , - . .
,« ́ ́ — , , , , .., .
, , . ( ) . . , .
, , , . - , . , , . , () .»
: .
? . ? .
. , — «» :-)
.
. : , , .
, , . ( ).
: , . : / .
:
- , : , -, (// ). . ( ).
- , , — . , : , «, » ( ), , «», . — .
- , . , — . — /, . — , , , , . - . , — . « ».
Total
- — .
- — .
- «» .
- , « » «» ( / ) — .
— , , . .
ePub
2022, .
. , , , ( 20 10 ) .
***
— :
- — . , .
Anda harus memahami bahwa sebagian besar tentang bekerja dalam tim scrum, dan ini adalah format kerja sama favorit saya.
***
Tiga prinsip: apa yang sering saya ikuti ketika mengerjakan suatu produk:
• Metode ilmiah
• Dalam setengah
• Hal terbesar yang dapat Anda lakukan
***
Instruksi atau "Rahasia Rahasia untuk Sukses Sukses dalam Sukses" - mengapa Anda tidak memiliki apa yang berhasil untuk orang lain dan bagaimana kami belajar menipu diri sendiri.
***
Jebakan korporasi
Anehnya bagi saya, posting beresonansi; bahkan orang asing bagi saya menulis dan berdiskusi, bahkan meminta untuk menerjemahkan ke dalam bahasa Inggris untuk dibacakan kepada kolega di negara lain
***
Rekrutmen sebagai produk atau "Vanya, temukan kami desainer!" -
Penjelasan rinci tentang kasus pengembangan produk dari awal, di dalam korporasi. Saya suka cerita ini, itu menginspirasi banyak teman dan mantan kolega, dan itu diceritakan (sudah tanpa saya) oleh Alpha Eychars di beberapa pertemuan dan konferensi.
Saya membumbui posting dengan tautan ke semua artefak proses - posting kami, publikasi Molino, artikel di Kommersant dan sebagainya. Saya sendiri tertarik untuk membandingkan apa yang saya pikirkan setahun yang lalu dengan apa yang saya tulis setahun setelah meluncurkan proyek. Fenomena ini dijelaskan dalam salah satu publikasi ilmiah Umberto Eco, dan di sini saya melihat cara kerjanya pada contoh saya. Menarik.
***
Produk pertama saya adalah
Ceritanya tentang bagaimana seorang teman sekelas dan saya membuat produk nyata yang membuat perusahaan. Ceritanya sudah dari tahun 1998, tetapi sangat mengungkapkan, menceritakan tentang bagaimana prinsip dan pendekatan saya telah berkembang, yang saya terapkan dalam pekerjaan saya dan yang kadang saya tulis di sini.
***
Dan tentang olahraga
Saya pikir di luar cakupan topik profesional, topik budaya fisik dilupakan dan sia-sia. Siapa pun yang mengingat saya bahkan tiga tahun yang lalu akan mengerti apa yang saya maksud: kesombongan dan pekerjaan membuat saya kelelahan dan itu tampak mengerikan. Saya berharap teks ini akan membantu orang lain untuk berpikir keras tentang kesehatan mereka di muka, tanpa menunggu hasil menyedihkan yang saya miliki.