-
Notifications
You must be signed in to change notification settings - Fork 3
/
Copy pathworkbook.html
2131 lines (2072 loc) · 196 KB
/
workbook.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Workbook.elixus.org</title>
<meta Http-Equiv="Content-Type" Content="text/html; charset=big5" />
<link REV="MADE" HREF="mailto:autrijus@autrijus.org" />
<link REL="stylesheet" HREF="ebx.css" type="text/css" />
</head>
<body style="background-color: white">
<p><a name="__index__"></a></p>
<!-- INDEX BEGIN -->
<ul>
<li><a href="#_w綵">名稱</a></li>
<li><a href="#泣彉">版權</a></li>
<li><a href="#__初_蓲_this_is_beta_software_">作者序: This is beta software.</a></li>
<li><a href="#1__槂_____w_絻琯__o___�">1. 簡介: 獨立接案這一行</a></li>
<ul>
<li><a href="#1_1___w_絻琯_初_o___�">1.1. 獨立接案者是什麼</a></li>
<ul>
<li><a href="#1_1_1___蓲諈榕h_a_x_琯_">1.1.1. 怎樣的人適合接案?</a></li>
<li><a href="#1_1_2______的_u___螵_">1.1.2. 常見的工作形式</a></li>
</ul>
<li><a href="#1_2___e_____騶_況">1.2. 委外市場現況</a></li>
<ul>
<li><a href="#1_2_1_______瀖__h_n_e__">1.2.1. 為什麼有人要委外?</a></li>
<li><a href="#1_2_2___蓲m___鎕e_鐻e__">1.2.2. 哪些專案比較容易委外?</a></li>
<li><a href="#1_2_3___琯_初的___�">1.2.3. 接案者的一天</a></li>
</ul>
<li><a href="#1_3___鎕x_琯_的_踆__b">1.3. 踏出接案的第一步</a></li>
<ul>
<li><a href="#1_3_1___q__蜤的_h___l">1.3.1. 從認識的人開始</a></li>
<li><a href="#1_3_2____發_踆o____">1.3.2. 開發其她案源</a></li>
<li><a href="#1_3_3___q_蓲__l___l_琯n_o_h">1.3.3. 從哪些案子開始接好呢？</a></li>
</ul>
</ul>
<li><a href="#2_____q___f___餩螵_蜤">2. 溝通: 達成最佳共識</a></li>
<ul>
<li><a href="#2_1___m_____q的_瀖__餩h">2.1. 專案溝通的基本原則</a></li>
<ul>
<li><a href="#2_1_1___n_趌o">2.1.1. 技術能力</a></li>
<li><a href="#2_1_2____皖泣_w__">2.1.2. 品牌知名度</a></li>
<li><a href="#2_1_3___螵h_螵f_o">2.1.3. 形象及口碑</a></li>
<li><a href="#2_1_4__表___m__">2.1.4. 表現專業</a></li>
<li><a href="#2_1_5__榮___�">2.1.5. 態度誠懇</a></li>
<li><a href="#2_1_6___踆麊榕h___q">2.1.6. 找對的人溝通</a></li>
</ul>
<li><a href="#2_2___m___騶潷e的___q">2.2. 專案執行前的溝通</a></li>
<ul>
<li><a href="#2_2_1_____燲__q">2.2.1. 洽談階段</a></li>
<li><a href="#2_2_2___d_鄋r___q">2.2.2. 需求分析階段</a></li>
<li><a href="#2_2_3___q_鸐__q">2.2.3. 訂價階段</a></li>
<li><a href="#2_2_4_____________q">2.2.4. 正式提案階段</a></li>
</ul>
<li><a href="#2_3___m___騶潷__q的___q">2.3. 專案執行階段的溝通</a></li>
<ul>
<li><a href="#2_3_1____發___q">2.3.1. 開發階段</a></li>
<li><a href="#2_3_2___籓蓲____q">2.3.2. 測試驗收階段</a></li>
<li><a href="#2_3_3__維嬅___q">2.3.3. 維護階段</a></li>
</ul>
</ul>
<li><a href="#3___趌u___m___w_榕p_騶�">3. 分工: 專案規劃與執行</a></li>
<ul>
<li><a href="#3_1___w_榕a的_m__">3.1. 規劃你的專案</a></li>
<ul>
<li><a href="#3_1_1___t_獥f_鎕a的_醂�">3.1.1. 確實了解你的客戶</a></li>
<li><a href="#3_1_2___t_螵鄋r的___n">3.1.2. 系統分析的重要</a></li>
<li><a href="#3_1_3___t_絻t_螵__獥潷p_y琯的_i_�">3.1.3. 確立系統中資料與流程的進行</a></li>
</ul>
<li><a href="#3_2___m__的綬_z">3.2. 專案的管理</a></li>
<ul>
<li><a href="#3_2_1___t_w_u__的_榕e">3.2.1. 確定工作的內容</a></li>
<li><a href="#3_2_2___醭h_vs___螵_">3.2.2. 個人 vs. 團隊</a></li>
<li><a href="#3_2_3___m___g_z的_____p_u__">3.2.3. 專案經理的角度與工作</a></li>
</ul>
<li><a href="#3_3___t_螵_發">3.3. 系統開發</a></li>
<ul>
<li><a href="#3_3_1__prototype的___n_�">3.3.1. Prototype的必要性</a></li>
<li><a href="#3_3_2__粿_____o___鎕y__的">3.3.2. 羅馬不是一天造成的</a></li>
<li><a href="#3_3_3___駻_發的_u_�">3.3.3. 選擇開發的工具</a></li>
<li><a href="#3_3_4_____醂_綬">3.3.4. 品質控管</a></li>
</ul>
<li><a href="#3_4___r_鰝榕潷f">3.4. 愉快的交貨</a></li>
<ul>
<li><a href="#3_4_1___t_獥x___i__">3.4.1. 確實掌握進度</a></li>
<li><a href="#3_4_2___潷f_m_�">3.4.2. 交貨清單</a></li>
<li><a href="#3_4_3_____q琯__">3.4.3. 順利結案</a></li>
</ul>
<li><a href="#3_5__發_燲n___粿__n__">3.5. 發生意外並不意外</a></li>
<ul>
<li><a href="#3_5_1___m_駻n__">3.5.1. 搶救意外</a></li>
<li><a href="#3_5_2___w___n__">3.5.2. 增加意外</a></li>
<li><a href="#3_5_3___m___m_a">3.5.3. 危機專家</a></li>
</ul>
<li><a href="#3_6___禬y禊踆">3.6. 創造雙贏</a></li>
<ul>
<li><a href="#3_6_1____視廡_醂駻醭d的____">3.6.1. 正視顧客對於需求的修正</a></li>
<li><a href="#3_6_2___n的泳_頨a__">3.6.2. 好的服務態度</a></li>
<li><a href="#3_6_3___琯_初_潷p">3.6.3. 接案者行銷</a></li>
</ul>
</ul>
<li><a href="#4_____h___x_鸐q_絻p維粿">4. 互信: 合約訂立與維繫</a></li>
<ul>
<li><a href="#4_1___p_醭q_絻__醭__銂榕x_�">4.1. 如何訂立一個有效的合約?</a></li>
<ul>
<li><a href="#4_1_1___n_q_絻鎕____鸐�">4.1.1. 需要訂立書面契約嗎?</a></li>
<li><a href="#4_1_2___p_醭________鎕____�">4.1.2. 如何完成一份書面契約?</a></li>
<ul>
<li><a href="#4_1_2_1___鎕攢__w_____�">4.1.2.1. 由誰簽名才有效?</a></li>
<li><a href="#4_1_2_2___n_g_w_嶱塺�">4.1.2.2. 要寫上日期嗎?</a></li>
<li><a href="#4_1_2_3___n粿_x___鎕____鸐o">4.1.2.3. 要簽幾份書面契約呢?</a></li>
<li><a href="#4_1_2_4_____瀖o___貜�">4.1.2.4. 什麼是契約附件?</a></li>
<li><a href="#4_1_2_5__塺_嶱n___駻__鸐榕e_蓲瀖�">4.1.2.5. 臨時要修改契約內容怎麼辦?</a></li>
<li><a href="#4_1_2_6___蓲u_螵q_l_l_醭__鸐__踆�">4.1.2.6. 傳真或電子郵件契約有效嗎?</a></li>
</ul>
</ul>
<li><a href="#4_2_____螒e_____╠__醭粿瑼榕鱌�">4.2. 一般委外契約應該具備的條款</a></li>
<ul>
<li><a href="#4_2_1___u___榕e">4.2.1. 工作內容</a></li>
<li><a href="#4_2_2___u___鱌s">4.2.2. 工作報酬</a></li>
<li><a href="#4_2_3___i_嶱塺豯__�">4.2.3. 付款時期及程序</a></li>
<li><a href="#4_2_4___o_螵__p">4.2.4. 費用開銷</a></li>
<li><a href="#4_2_5__硬樥___潷螵獥_">4.2.5. 硬體設備或資材</a></li>
<li><a href="#4_2_6__琯__">4.2.6. 稅捐</a></li>
<li><a href="#4_2_7___x_鸐__踆塺_">4.2.7. 合約有效期間</a></li>
<li><a href="#4_2_8___x_鸐__�">4.2.8. 合約終止</a></li>
<li><a href="#4_2_9__泣緇_鎕m___�">4.2.9. 爭端解決機制</a></li>
<li><a href="#4_2_10___q泣_e_f_醂_">4.2.10. 通知送達方式</a></li>
<li><a href="#4_2_11___x_╣馲鍱__�">4.2.11. 合約轉讓或繼受</a></li>
<li><a href="#4_2_12___蓲k">4.2.12. 準據法</a></li>
</ul>
</ul>
<li><a href="#5___i_潷__p_騢螒q_d精">5. 展望: 如何精益求精</a></li>
<ul>
<li><a href="#5_1___t_絻鐻蛷v泣_o">5.1. 確立核心競爭力</a></li>
<ul>
<li><a href="#5_1_1___鄋r_趌螵c_x_d">5.1.1. 分析技能及列出需求</a></li>
<li><a href="#5_1_2___w_榕i___醂_">5.1.2. 規劃進修方案</a></li>
<li><a href="#5_1_3___o_鸐__d_b發_i___�">5.1.3. 保持健康、發展興趣</a></li>
</ul>
<li><a href="#5_2___p_醭__銂榕蓲絻h">5.2. 如何有效的學習？</a></li>
<ul>
<li><a href="#5_2_1___w_i_n_趌o">5.2.1. 增進技術能力</a></li>
<li><a href="#5_2_2___w_i_醭__趌o">5.2.2. 增進商業能力</a></li>
<li><a href="#5_2_3___w_i___q_趌o">5.2.3. 增進溝通能力</a></li>
</ul>
<li><a href="#5_3__芹_s_p_u_w_u__">5.3. 社群與線上工會</a></li>
<ul>
<li><a href="#5_3_1____發初網_�">5.3.1. 開發者網路</a></li>
<li><a href="#5_3_2__琯_蟉bs_p_q___s">5.3.2. 善用BBS與討論群</a></li>
<li><a href="#5_3_3___醭____p_礱_">5.3.3. 草根集會與組織</a></li>
</ul>
<li><a href="#5_4_____鎕餩l_x_嬅�">5.4. 開放原始碼文化</a></li>
<ul>
<li><a href="#5_4_1___踆螵j___m_�">5.4.1. 採用既有套件</a></li>
<li><a href="#5_4_2___鎕p_m_醭蒫o">5.4.2. 參與套件研發</a></li>
<li><a href="#5_4_3___d_鸐s的_p_�">5.4.3. 主持新的計劃</a></li>
</ul>
<li><a href="#5_5___琯__h__的_u__">5.5. 接案以外的工作</a></li>
<ul>
<li><a href="#5_5_1__演塺_螵粿q__">5.5.1. 演講及研討會</a></li>
<li><a href="#5_5_2___d_鸐v_m_繺_">5.5.2. 主持訓練課程</a></li>
<li><a href="#5_5_3___g___螵x泣">5.5.3. 寫作及出版</a></li>
<li><a href="#5_5_4___n樥___螒螵潷p">5.5.4. 軟體包裝及行銷</a></li>
</ul>
<li><a href="#5_6___踆o_燲p_w_漯榕駻�">5.6. 其她生涯規劃的選擇</a></li>
<ul>
<li><a href="#5_6_1__琯___獥n槂">5.6.1. 策略性就職</a></li>
<li><a href="#5_6_2___潷禬_">5.6.2. 自行創業</a></li>
<li><a href="#5_6_3_____p瘔__">5.6.3. 兼職與轉業</a></li>
</ul>
</ul>
<li><a href="#琯_y___o___鎕p_醭駻磲�">結語: 這本書如何誕生的</a></li>
<li><a href="#蜬_絻鶌___">藝立協簡介</a></li>
<li><a href="#_u____初__餩__撋__榕蓲">各章作者(依中文筆劃序)</a></li>
<li><a href="#_醭p_x_�">協同訪問</a></li>
<li><a href="#___潷__�">材料提供</a></li>
</ul>
<!-- INDEX END -->
<hr />
<p>
</p>
<h1><a name="_w綵">名稱</a></h1>
<p>The Workbook Project</p>
<p>
</p>
<hr />
<h1><a name="泣彉">版權</a></h1>
<p>傲爾網 <<a href="mailto:members@ourinet.com">members@ourinet.com</a>> 版權所有，2001 年。</p>
<p>此文件是開放文本；你可以依 Open Content License 以數位形式進行傳佈及更動。</p>
<p>請參見 <a href="http://opencontent.org/opl.shtml">http://opencontent.org/opl.shtml</a>。</p>
<p>
</p>
<hr />
<h1><a name="__初_蓲_this_is_beta_software_">作者序: This is beta software.</a></h1>
<p>這本書是許多人共同學習的筆記。這群人彼此差異甚大，少數的共同點是：1)網路是生活與工作的重要部分、2)與其聽從他人指示做事，更傾向於自己決定自己負責，以及3)覺得自發性的合作是解決問題的好方法。</p>
<p>2001年初，「身為獨立接案者，至少應該知道哪些事情？」這個問題激起了大家的興趣，於是就分頭找資料、採訪、辦討論會，寫下了這本書。</p>
<p>既然是一篇聯合創作的作品，這篇「作者序」自然無法概括所有參與者的意見，而兩位筆者也不打算這麼做。這裡祗打算將我們平日的溝通所形成的某些共識告訴大家；其她作者各自的看法, 妳可以透過網路上的各種管道來認識，或是加入我們每週日下午兩點在紫藤蘆（台北市新生南路三段16巷1號）的聚會.</p>
<p>這本書的撰寫過程裡，我們嘗試了「分散式網路團隊」這種工作型態：成員之前彼此沒有隸屬關係、沒有外在獎懲制度、自己掌握工作進度，而幾乎所有溝通都透過網路進行、對外界完全透明，歡迎任何人參與。</p>
<p>實際運作起來，工作的效率連我們自己都感到喫驚。當然，許多大規模的開放原始碼（Open Source）計劃，早已確立了藉由網路社群執行工作的前例。但是在親身領略之後，面對未來藉由「虛擬辦公室」的工作方式與流程，這本書為我們帶來更大的信心。</p>
<p>我們自己知道，這本書的內容並不完美；以軟體的品質而言, 祗相當於測試版（beta version）而已。但是，基於「儘早釋出, 儘快釋出」（Release early, release often）的精神，我們還是將它呈現在妳面前，希望能拋磚引玉，激發網路上更多相關的討論和交流。</p>
<p>作者們會在 <a href="http://elixus.org/workbook/">http://elixus.org/workbook/</a> 持續不斷地增修內容，逐漸結集更多過來人的經驗，增加它對新手的價值。如果妳有獨立接案的經驗談，願意接受訪問／幫忙訪問，或覺得書裡的任何文字有瑕疵或不足之處，歡迎妳寫信到 <a href="mailto:workbook@elixus.org">workbook@elixus.org</a> 參加這個計劃的運行。</p>
<p>將自己手上的資源開放給所有人分享，一直是為作者們所認同的觀點。因此，我們遵循《黑話檔案》（Jargon Files）等網路著作的傳統，自動放棄了電子出版物的獨家重製權。也就是說，妳可以在前述網址下載這本書的完整內容，也可以在不更動作者名稱版本和內容的前提下，在網路上任意轉載這篇文章。（完整的授權條款，請參考網站上的資訊）</p>
<p>但是，如果妳覺得這本書的內容有些參考價值，我們還是建議您購買印刷版本：由商智出版社在 2001 年印行的《獨當一面 - 數位獨立接案的規畫與管理》。這並不是為了我們的荷包，因為所有作者都不支領版稅；主要原因是，商智出版社願意與開放原始碼的創作方式合作，在台灣是件首開先例的創舉，讓我們非常感謝。如果這本書賣得不錯，或許能鼓勵未來更多結合網路創作和實體傳播的計劃，讓讀者能自由地參與創作和對話，也讓出版者獲得應有的報酬。</p>
<p>獨立接案者在台灣的路雖然不能說是剛開始，但是距離成熟顯然還需要許多努力。在世界上的每個角落，積極而自主的知識工作者一向是資訊交流和創新的前鋒, 也對台灣軟體業界的存續有直接的影響。既然我們還有相當長的路要走，就從彼此的溝通、分工和互信開始吧！</p>
<p>
</p>
<hr />
<h1><a name="1__槂_____w_絻琯__o___�">1. 簡介: 獨立接案這一行</a></h1>
<p>在資訊業界，獨立接案者主要的工作內容在於提供客戶服務。服務項目則包含電腦硬體配備、軟體設計、網路架構及資料處理等相關的各種事情。妳可能是幫客戶組一台電腦、架一個伺服器，也可能是設計一個網站或是規畫撰寫一套行政流程系統。視客戶需求與妳的個人能力而異。</p>
<p>翻開這本書，妳的第一個疑問可能是，何謂獨立接案者？一個獨立接案者要做些什麼事、面對哪些問題、該如何定位自己等。這一章裡，我們將對獨立接案者做概略的描述，讓妳對這個工作有基本的認識。</p>
<p>
</p>
<h2><a name="1_1___w_絻琯_初_o___�">1.1. 獨立接案者是什麼</a></h2>
<p>獨立接案者的工作時間並不固定，妳可能長達一年的做為一個專案的專案管理員，也可能同時負責六個工作而每個工作的時限只有一個月。工作地點因內容而異，可能是到府服務，到某個大型企業或是自己在家工作。身份也非常多變，可以是一間公司暫時的員工，也可以是獨立的外聘人員，跟公司內的特定團隊合作與溝通。</p>
<p>此外，身為獨立接案者意味著妳必須同時處理多種不同的課題。讓客戶瞭解妳的服務內容、妳能幫客戶解決什麼問題，以何種方式讓她們看到成果等。面對不同的專案，妳會需要不同的技術以及相關的管理技巧；判斷並且提供方法解決技術上的問題。</p>
<p>獨立接案者跟一般公司的雇員有何差別呢？到公司工作的話，妳的職位、工作內容與方式就是固定的，由公司的制度決定。有張專屬的辦公桌，基本的上下班時間，在公司規定時間內完成妳的工作。合約部份，妳跟公司簽長期的僱約，半年、一年或更長。福利方面，則享有公司提供的各種福利，勞健保、員工旅遊、公司社團活動、年節獎金、紅利股票等。</p>
<p>若是獨立接案者，妳與客戶的關係就不是那麼絕對。合作模式由雙方溝通後決定，妳通常要訂立自己的工作時間表與工作內容。合約也依工作方式有所不同，妳要自己準備。跟公司之間可能是外聘人員，或是臨時僱員。一般而言，外聘人員不享有公司提供的員工福利，臨時僱員還有可能。妳會有比較大的自主性，但是相對的，也需要花時間和心思來處理這些事情。</p>
<p>
</p>
<h3><a name="1_1_1___蓲諈榕h_a_x_琯_">1.1.1. 怎樣的人適合接案?</a></h3>
<p>清楚一個獨立工作者的性質之後，接下來要思考的就是，自己到底適不適合從事這個工作。這邊的意思不是說妳是否具備足夠的技術能力，而是妳個人的人格特質是不是適合。技術是可以經由時間跟經驗累積起來的，然而，人格特質卻較難藉著後天的訓練來改變。在一個分工的體系下，有些人就是喜歡在公司裡面任職，而有些人覺得當獨立工作者比較愉快。這中間沒有優劣之分，不過是人格特質上的差異。</p>
<p>在這一節裡，我們就要來談談在獨立工作者身上常見的人格特質有哪些。</p>
<dl>
<dt><strong><a name="item__bfw_a5絻a1b_a6a5d_a9獥b1j">獨立、自主性強</a></strong><br />
</dt>
<dd>
團隊工作的時候，除了聽從負責人的決定之外，還會有自己的想法與判斷。面對問題的時候習慣自己決定而非只由她人決定。獨立工作者並不意味著妳的工作量會比別人少，只是妳對自己的工作時間與內容有較大的主控權。不需要朝九晚五上下班打卡，但是工作一樣要做。沒有人告訴妳什麼時候要做什麼事，妳必須自己決定一切。若是缺乏良好的自主能力，無法自己安排時間的話，最後可能會流於懶怠以致一事無成。
</dd>
<p></p>
<dt><strong><a name="item__bfn_b7_a5的_a6潷b0獥a4o">積極的行動力</a></strong><br />
</dt>
<dd>
獨立工作者要能為自己尋找各種工作機會。對於資訊，不只被動接收，還要有主動蒐集的能力。對事物有一定的敏銳度，可以快速判斷這是否為妳有興趣的工作，主動爭取。
</dd>
<p></p>
<dt><strong><a name="item__bc鐻a9醭b7_be_b3q">樂於溝通</a></strong><br />
</dt>
<dd>
一個專案從開始到結束，獨立工作者的工作內容並非只是單純的撰寫程式碼，溝通佔了很主要的部份。如果生性不好與人交談，那麼從事這個工作就會比較辛苦。
</dd>
<p></p>
<dt><strong><a name="item__b0l_a8d_a6h_bc螒a4u_a7_40泣ac榮">追求多樣工作狀態</a></strong><br />
</dt>
<dd>
每個人對工作內容的要求不一，若妳希望的工作是只要做好自己份內的事，穩定的拿薪水，不需要做其她額外事情的話，獨立工作者這份職業對妳來說可能就太刺激。如果妳不喜歡單一重複的工作內容，追求改變。對事物持高度好奇心，不排斥學習新東西。那麼，當個獨立工作者就會蠻愉快的。
</dd>
<p></p>
<dt><strong><a name="item__a6w_a9醭a4_a3粿ad_a9w">安於不穩定</a></strong><br />
</dt>
<dd>
獨立接案者的工作收入與生活方式並不固定。妳沒有一定的工作時間與固定薪水。對一些人來說，這會造成不安全感。妳必須考量自己是否可以接受這種生活方式。
</dd>
<dd>
<p>說了這些東西，並不是說一定要具備以上條件才能當獨立工作者，只是說有這些傾向的人可能會比較喜歡這份工作。真正要知道自己適不適合其實很簡單，實際做一次就知道了。</p>
</dd>
<p></p></dl>
<p>
</p>
<h3><a name="1_1_2______的_u___螵_">1.1.2. 常見的工作形式</a></h3>
<p>由於獨立接案的機動性極高，不同的專案需求，往往會衍生出相應的工作形式。除了底下所列四種最常見的方式之外，如團隊電子通勤（telecommuting team）等新的模式也不斷被提出；如果能靈活地運用不同的工作形式，在執行交付的專案時必然能事半功倍。</p>
<dl>
<dt><strong><a name="item__a4_40_a4h_a4_bd_a5q">一人公司</a></strong><br />
</dt>
<dd>
以個人名義獨立工作，動態地接各種案子，與客戶聯絡、談需求、訂合約。個人的工作模式通常是：獲得到案子的資訊，然後妳跟案主聯絡，確認實際需求，評估個人的接案意願與能力，決定是否接案。接下來，跟客戶談定合約細節與合作方式，工作、交案。
</dd>
<p></p>
<dt><strong><a name="item__a4p_ab_ac_a4u_a7_40_ab�">小型工作室</a></strong><br />
</dt>
<dd>
小型工作室是由固定幾個人組成的工作團隊，以團隊名義接案，各人有較明確的分工。會有人負責聯絡與溝通，有人做程式撰寫，這種工作型式對於不習慣凡事一把抓的人來說會比個人獨立工作來得適合。合約方面，如果工作室有登記的名稱就以工作室名義與客戶簽約，或是由一人出面簽約，不需要每個成員都單獨與客戶簽約。
</dd>
<p></p>
<dt><strong><a name="item__bc醂ae撉榕b6_7d發_b9螵b6_a4">暫時的開發團隊</a></strong><br />
</dt>
<dd>
一群個人，為解決某個特定計畫動態產生的開發團隊，在計畫完成後就解散，沒有固定的合作關係。這種開發團隊的形成是非常動態的，通常是一個人接了案子，發現自己做不完，然後找人幫忙，有意者加入，形成團隊。每個人各自與案主簽約。另一個情況是，案主只跟團隊的負責人簽約，其她成員是由這個人找來的。此時這些成員就是跟負責人談而非案主，或許會簽約，也可能只是談好合作與付錢的方式而不簽約。
</dd>
<p></p>
<dt><strong><a name="item__a4_bd_a5q_a5_7e_b8u_a4h_ada9鍕_7b_ae嶱b9琯ad�">公司外聘人員或臨時僱員</a></strong><br />
</dt>
<dd>
一組人或個人在合約期限內與公司配合，與公司內的特定部門合作，完成公司的專案。或是，以外聘人員的身份為公司提供特定的服務，顧問通常就是這種型式。這種情況的話，妳可能會需要配合公司的制度上下班，在公司內有暫時的工作位置，看客戶公司的要求以及合約而定。
</dd>
<p></p></dl>
<p>
</p>
<h2><a name="1_2___e_____騶_況">1.2. 委外市場現況</a></h2>
<p>想要成為獨立接案者的人都會有一些疑慮，就是關於這個市場的成熟度如何，我到底是否可以藉由接案來維持正常的收入。那麼我們就先藉由一些數據來看看現在委外市場的情形如何。</p>
<p>Gartner Group在2000年所做的調查顯示，所有的公司都面臨到以現有的人力無法負擔資訊服務的需求，而有73%的企業願意將公司內的資訊系統委外。也就是說目前大約四分之三的企業都希望能將公司內的資訊系統委外開發。</p>
<p>而近一年來雖然全球經濟發展趨緩，MIC對台灣企業應用軟體的成長率調降，但是卻依然維持約28%的成長率向上成長。而且全球的資訊委外市場也將在近幾年會有大幅度的增加，台灣也會緊跟在這股風潮中。</p>
<p>在資訊系統委外需求的比例上，大約可以分為金融（35%），政府（23%），製造（20%），電信（15%），至於接下來幾年預估成長最快的系統將是供應鏈管理（Supply Chain Management; SCM），客戶關係管理（Customer Relationship Management; CRM） 企業資源規劃（Enterprise Resource Planning; ERP）軟體等；這些部分也將成為接下來企業委外的重要類別。而每年企業應用軟體委外開發的金額約有一百多億，並預估以每年28%的速度增加。</p>
<p>從這些數字就可以看到，接下來企業資訊委外將會成為一種趨勢，對於希望進入這個產業的人而言，將會是一個很好的進入點。</p>
<p>
</p>
<h3><a name="1_2_1_______瀖__h_n_e__">1.2.1. 為什麼有人要委外?</a></h3>
<p>「委外」這樣的詞彙對於一般人也許並不太熟悉，但是這樣的觀念絕對不算是一種創新的觀念，其實大部分的人每天都有許多事情是委外進行的。如果以這樣的看法來思考「委外」這件事情，顯然會讓我們感覺容易、也親切許多。我們不妨回憶一下我們手上的哪些事是經常委外，而且為什麼需要「委外」，那麼我們就很容易可以發現為什麼企業中存在著許多需要委外的專案。</p>
<p>我們隨便舉幾項個人委外的實例：許多人總是經常因為某些原因無法回家裡吃飯，而必須在外用餐，在這樣的情況下委外就產生了。或是如果你選擇搭乘捷運，以某種角度來看，當然也可以納入委外的範圍內。</p>
<p>當然，以公司經營的角度來看，委外顯然也是非常好的方式，有時甚至可以說是不可避免的方式。舉例來說，如果你是一家出版社，那麼除非你所出版的書籍數量多到需要一家印刷廠，否則你又何必自己經營印刷廠呢？</p>
<p>這樣的委外情形在許多產業中都已經算是行之有年，也已經有了相當不錯的上、下游關係及還算健全的制度。在台灣，我們經常聽到某些公司幫國外的電腦、手機等等大廠代工，這顯然也是一種典型的委外狀況。其他像會計師、律師都是很好的例子，這些人並非是公司的員工，一般的公司也並不常需要這樣的人才，但是在必要的時刻卻是完全不能少的，於是委外的情形就發生了。</p>
<p>從剛剛所提到的內容看起來，公司在許多情形下會很容易有委外的工作產生。當然，我們想要了解的是一般企業在哪些情況下容易會有將自己的需求委外，如果我們可以清楚的知道這件事情之後，那麼也就可以藉由對這些情形的分析，知道在資訊技術方面有沒有這樣的機會讓企業將自己的系統委外；或者對於業者來說，他們也可以解除一些對於自己是否應該將資訊系統委外的疑惑，並加強企業對於資訊系統委外的確認與信心。</p>
<p>首先，我們應該想到，對於每一家公司幾乎都需要的會計師或律師而言，為什麼卻大多委外給會計師事務所或是律師事務所呢？這個問題並不難回答，因為一般公司對於會計師或律師的需求並不足以需要僱請專用的會計師或律師，何況這兩種人才物以稀為貴，也不是一般中小型企業的人事費用所負擔的起。</p>
<p>既然如此，當然在需要時以委外的方式比較方便、也經濟許多。類似的情形也發生在軟體、資訊技術方面，一般公司在目前、或是可以預見的未來對於資訊系統的使用需求將會有急速的增加，但是資訊系統無論在系統架設或是軟體設計方面都不能算是一項長期性的工作，仔細想想，如果一家公司聘用了三、四位系統開發的相關工程師，那麼當他們花費了幾個月將系統開發完成後，公司在系統開發方面的需求已經降低或是結束的時候，這些工程師將無法再被賦予適當的任務，這無論對公司或員工都不是一件好事。</p>
<p>因此對於這些並不算是長期的需求，將這些系統委外顯然是比較經濟以及實際的作法。其實資訊顧問也經常是以這樣的方式存在，他們並不是公司裡的正式員工，而僅僅在公司的資訊系統發生問題時提供解決的方式與建議，這當然也是資訊系統委外另一類明確的例子。</p>
<p>事情顯然不只是這樣，讓我們看看台灣在資訊硬體部分的例子。台灣的某些硬體產業非常發達，經常可以在合理的價錢下可以製造出品質優良的產品。這對於許多國外大廠而言是非常具有誘因的，因為許多產品在國外製造的生產成本太高，而品牌行銷、設計的利潤遠大於勞力密集的生產製造，因此這些國外大廠就把他們所需要的產品委外給台灣的代工廠代工。</p>
<p>類似的情形也會發生在軟體相關的部分，也就是一些規模較大的軟體廠商對於手上的案子評估，如果是人力不足，或為了降低成本，提高利潤，於是就將接到的案子轉包給其他小型工作室或個人接案者。</p>
<p>上述的情形幾乎是目前一般公司或專業的資訊公司會利用委外來進行軟體開發的原因，當然，其他還會有一些不同的因素，但如果以比例來觀察，因為其他情形而委外的案子顯然在比例上而言是顯著比較少的，有些不同也只是上述的這些原因以某些不同的形式衍生。
讓我們嘗試舉一些其他的例子來解釋，不久前網路產業曾經流行了一陣子應用軟體服務提供的服務，也就是利用一般公司不必要為了使用某些軟體而僱用程式開發的人員，並且因為大家共同租用而可以降低成本。在某種程度上，這樣的模式就是利用了一般公司對於軟體需求的特性，其他的一些考量當然在於使用效能，隱密性等等，不過這並不在我們討論的主題中。</p>
<p>就以上述的一些觀點來看，目前一般企業對於軟體的委外似乎雖然已經慢慢出現需求，但是卻由於一些客觀環境的發展緩慢，讓軟體委外還不足夠成熟到可以讓大多數的人能放心的進入這個領域。但是可以預期的是接下來所有產業對於資訊化的需求將會持續的增加，對於系統開發者的需求當然也會跟著成長，那麼將會不斷刺激軟體委外市場的發展，對於目前現有的軟體產業或是軟體自由創作者的結構也會有關鍵性的變化。而事實上，目前軟體產業也持續在改變之中，自由工作者的發揮空間也逐漸變大。</p>
<p>
</p>
<h3><a name="1_2_2___蓲m___鎕e_鐻e__">1.2.2. 哪些專案比較容易委外?</a></h3>
<p>經由上述的討論我們可以更容易的去了解企業為什麼會有委外的想法，如果我們從這些想法之中去思考會有哪些專案會委外顯然就變的容易許多了。簡單的說，一般企業中需要以專案的方式去進行資訊化的部分，由於他們並不願意，也沒有需要特別聘請固定的員工來進行，那麼專案委外就成了一種容易而且重要的方式了。當然，目前有許多企業的e化過程中更容易產生許多委外的專案，接下來我們就將針對這一個部分來進行討論。</p>
<p>在幾年前，一般的企業進行資訊化的流程大多以財務為主，而且會進行資訊化的也都是規模還不算小的公司。而且資訊多屬封閉，所有的資料都幾乎只能由財務或高級主管才能獲得。所謂的資訊化的工作只要在於幫助財務人員作帳務的清查與計算，嚴格說起來也並不能算是流程的資訊化，而只是比較方便的試算表。</p>
<p>在這個階段，企業委外的系統其實是非常的少，而且有一大部分是落在規模較大的軟體公司手上，對於接案者來說是非常的辛苦的一段時間。這樣的情形在最近幾年有了相當大的改變，最近幾年來由於網路快速竄起、資訊流通快速等等的因素，使得不但企業委外的方向有持續增加的趨勢，也使得更多企業（甚至包括許多的中小型企業），產生更多委外的需求。而委外的軟體也不再只是以財務管理的專案為主，相反的，資訊e化、網站規劃、架設都是近兩年來委外專案中成長較快的。而網站架設的部分則包括了Internet與Intranet，Internet中例如CRM （客戶關係管理）或是電子商務的部分都是委外相當熱門的項目。而Intranet中則有EIP（企業資訊入口）或KM（知識管理）等，其他有一些和電子流程相關的專案也是頗具有吸引力的。</p>
<p>如果我們仔細觀察這些熱門的商品，大概歸納出一些值得參考的方向。首先，由於有許多企業對於資訊系統的需求在於能夠幫他們處理為數不少的資料，因此絕大多數的系統和資料庫必然有不可分離的關係。接下來我們也可以發現，網路程式顯然是近幾年的趨勢，所以企業要求以Web當作統一的介面，也幾乎快要成為另一種常用的標準。而電子郵件的使用也日漸頻繁，因此應用程式和電子郵件的溝通也是不可或缺的。網路程式中和使用者之間的各種互動顯然也是最近軟體委外的當紅炸子雞，幾乎所有委外的網站中都包含了這些功能，甚至於就是網站的主要功能。</p>
<p>至於許多過去經常委外的軟體種類，也大多改用Web作為使用者介面，而成為企業內部網站的其中一部份，其中例如人力資源管理、倉儲管理等都屬於這一類型。如果你是從大公司的手上轉包一些案子，那麼你也許會接到一些比較龐大的系統，目前比較熱門的系統包括了ERP（Enterprise Resource Planning）、EIP或KM等等。其中又以ERP是比較複雜的，因為他經常包含了公司內部的進銷存管理、金流、物流等等，由於複雜度較高，牽涉的範圍較廣，案子的金額也比較高，所以一般的接案者接觸的機會比較少。</p>
<p>
</p>
<h3><a name="1_2_3___琯_初的___�">1.2.3. 接案者的一天</a></h3>
<p>「SOHO」族，這樣的工作形式聽起來似乎是讓人羨慕的，但是實際狀況到底如何？是否就跟大家想的一樣：「錢多、事少、離家近，睡覺睡到自然醒」呢？我想答案當然很明確，這樣的工作大概只有在作白日夢時想想吧！那麼一個接案者到底需要作哪些事，不是只有寫寫程式而已嗎？關於這一方面，相信有許多人都相當好奇，既然如此，那麼我們就來看看接案者的一天，讓大家更了解接案者的生活到底是如何。</p>
<dl>
<dt><strong><a name="item__a6_ad_a4w_8_3a30">早上 8:30</a></strong><br />
</dt>
<dd>
鬧鐘響了，「睡覺睡到自然醒」的願望顯然沒有辦法達成。九點半和張經理約在他們的辦公室要做Review Meeting，這是一個知識管理的網站，已經接近結案了，所以最近要開始作 Review，希望接下來可以輕鬆的交貨。
</dd>
<p></p>
<dt><strong><a name="item__a6_ad_a4w_9_3a30">早上 9:30</a></strong><br />
</dt>
<dd>
Review的狀況還算不錯，除了張經理又提出了一些新的需求之外，程式部分應該都可以運作正常了，不過已經告訴他幫他解決這次的需求了之後，下次就沒辦法了，否則不就掉入了無限迴圈了嗎？再不結案的話，錢就一直無法進帳了！
</dd>
<p></p>
<dt><strong><a name="item__a4w_a4醂11_3a00">上午 11:00</a></strong><br />
</dt>
<dd>
今天開了一個半小時的會，比起上個案子動不動就是三個小時的會顯然輕鬆多了，不過還是不懂，就是一些小的需求，直接用E-Mail聯絡就好了啊！為什麼一定要開這麼冗長的會？或是電話不是也很方便嗎？還是沒人注意到效率問題… 該準備一下下午要給雜誌社的Proposal，希望可以接下這個案子，畢竟他們要的功能都有現成的套件可以用了，這樣接起案子就輕鬆的多了。
</dd>
<p></p>
<dt><strong><a name="item__a4_a4_a4醂12_3a00">中午 12:00</a></strong><br />
</dt>
<dd>
民以食為天，就算再忙也不能忘了吃飯的時間，畢竟辛苦工作之外，也要好好的照顧自己的身體。反正一點半才要去簡報，輕鬆吃個飯的時間還是有的。
</dd>
<p></p>
<dt><strong><a name="item__a4u_a4醂1_3a30">下午 1:30</a></strong><br />
</dt>
<dd>
這家雜誌社已經來了第三次了，希望這次的簡報可以讓他們滿意，那我就有希望可以接下這個案子，他們要的上稿系統都已經有了開放出來的套件，只要修改成他們要的功能就容易的多了。完全展露出軟體重用的好處，而且我建議他們使用的也都是開放原始碼的系統，省下那麼多錢，他們的總經理應該很高興吧！
</dd>
<p></p>
<dt><strong><a name="item__a4u_a4醂2_3a30">下午 2:30</a></strong><br />
</dt>
<dd>
剛剛看他們的表情，看來這個案子應該沒什麼問題了，這個月應該 確定能不能接，如果一切順利的話，下個月就可以交貨了。顯然，接案者也要具備業務員的功力，否則都沒有案子可能也不是件好事。該回去開始作業了，還有一堆事情要做。
</dd>
<p></p>
<dt><strong><a name="item__a4u_a4醂3_3a00">下午 3:00</a></strong><br />
</dt>
<dd>
怎麼一回來又看到這麼多E-Mail，上次幫吳總他們寫的程式掛了，應該是系統負荷過高，晚上再檢查一下他們的系統。上個月交貨的聊天室系統終於把錢匯給我了，看來晚上可以慶祝一下。只是不知道手上的東西能不能趕完，否則這個禮拜週末沒得放假可就慘了。
</dd>
<p></p>
<dt><strong><a name="item__a4u_a4醂4_3a00">下午 4:00</a></strong><br />
</dt>
<dd>
要幫小趙介紹的那家貿易公司寫系統規劃書，他們只要架設公司的網站，公司裡又沒有MIS的人，建議他們用主機代管的方式好像是比較好的，否則到時候問題可又不少，只是預算方面又是另一個問題。不過比起我上次幫那家紡織公司做的案子似乎還容易的多，他們用那種舊型的資料庫，資料的轉換還讓我花了一番功夫，下次這種傻事還是少作為妙。
</dd>
<p></p>
<dt><strong><a name="item__b1絻a4w_9_3a00">晚上 9:00</a></strong><br />
</dt>
<dd>
看來今天的工作終於要告一段落了，寫完了系統規劃書，也幫吳總把系統修好了，看來還是要降低系統的負荷，否則機器很容易掛掉的，我可不想整天維護那套系統！他想要好一點的效率，就叫他多買一部機器，也該讓他簽下維護合約才行。早上張經理要的功能也都加上了，發了mail 給他，如果測試都沒問題的話，應該下禮拜就可以交貨了，不過希望不用再去開那種讓人頭暈的會了。雜誌社的報價單也傳過去了，我想應該很快就會有回應，所以手上的案子要先結束掉才行。不過時間不早了，現在還是先休息一下。
</dd>
<p></p></dl>
<p>接案者的工作顯然並不像一般人所想像的那麼單純，要把原來由許多人做的事全部自己完成，還會因為所面臨到的企業規模、文化的不同而產生不同的工作。但是其中的自我學習、成長卻也是有趣的，如果你想成為一個獨立接案者就必須有這樣的認識。當然其中還包含了許多部分，例如自己時間的調整、分配，自我的學習都是重要的挑戰，也是作為一個獨立接案者吸引人的地方。</p>
<p>
</p>
<h2><a name="1_3___鎕x_琯_的_踆__b">1.3. 踏出接案的第一步</a></h2>
<p>獨立工作者一開始時容易碰到兩個瓶頸：無法找到足夠多的客戶養活自己，或是本身的專業能力不足。解決第一個問題可以從發展有用的自我行銷技巧著手。很快地，妳就會發現，發掘客戶是所有非技術性工作中最重要的部份，其她所有的商業技巧都比不上如何成功地將自己推銷出去這件事重要。在這一節裡，我們就要告訴妳幾個常見的接案管道，接案時要如何選擇案子，以及一些幫助妳成功完成專案的小秘訣。</p>
<p>
</p>
<h3><a name="1_3_1___q__蜤的_h___l">1.3.1. 從認識的人開始</a></h3>
<p>僅管妳已瞭解自己定位、做好心理準備，也具備了基本的技術能力，在案子尚未到手前，仍稱不上是一名獨立工作者。然而，正如同錢不會自動從天上掉下來，案子也不會自己跑來找妳。想接案子，就要自己去找。</p>
<p>對想接案的新手而言，透過人際關係是比較容易開始的方法。妳可以從周遭在相關領域工作的朋友、學校系所上的研究室問起是否有需要人手的專案計畫，表達妳想參與的意願，請她們幫妳留意相關資訊。若是這些人正好有需求又覺得妳可以試試看的話，就會把案子轉介給妳，或是讓妳加入開發團隊幫她們做其中一部份。</p>
<p>比起直接去接陌生人的案子，由認識的人中介案子，對獨立接案者有這些好處：</p>
<dl>
<dt><strong><a name="item__a6_b3_a4h_a5i_a8鎕bf瀴b8�">有人可供諮詢</a></strong><br />
</dt>
<dd>
身為獨立工作者所應具備的不只是技術能力，聯絡、溝通、管理、行銷等也是重要的條件。要馬上就把這些技巧學會可說是不可能的事，尤其，當接下案子的時候，妳無法預知在整個專案發展過程中將會遇到什麼問題。遭遇困難的時候，有個熟悉狀況的人在旁提供意見跟經驗，會讓妳輕鬆不少。
</dd>
<p></p>
<dt><strong><a name="item__b4_a3_b0泣a4_ac_abh">提高互信</a></strong><br />
</dt>
<dd>
朋友會介紹給妳的客戶，至少是她認為可以信任的。雙方在合作之初存在著善意。妳比較不用擔心會被欺負或是案子出了意外最後變成做白工。此外，因為是認識的人，妳會比較容易放下身段向她請教問題，得到的答案也較誠懇客觀。
</dd>
<p></p>
<dt><strong><a name="item__ad_b0_a7c_b7_be_b3q_a6_a8_a5_bb">降低溝通成本</a></strong><br />
</dt>
<dd>
從友人處妳可以獲得到比較詳細的資料，增加對客戶的瞭解。減少溝通過程當中，與客戶之間因陌生而造成的溝通成本。
</dd>
<dd>
<p>一個人馬上獨立接案是很辛苦的，為了避免在起步就困難重重，我們會建議妳從加入小型開發團隊作起，與認識的人合作對新手而言有些額外的好處：</p>
</dd>
<p></p>
<dt><strong><a name="item__a8_7d_a6n的_be蓲b2葮瀴b9�">良好的學習環境</a></strong><br />
</dt>
<dd>
初學者開始最需要磨練的就是技術，團隊合作提供一個分工的環境。妳只需要專注地把自己負責的部份瞭解清楚實做出來就好，不用花費心思在其她的人事溝通或系統設計領域，遇到問題時也有管道可以迅速找到人支援。在這樣的環境底下，妳可以把基礎的實做能力練好，往學習其她技巧的領域邁進。
</dd>
<p></p>
<dt><strong><a name="item__a7醭a6_b3_abo_bb�">更有保障</a></strong><br />
</dt>
<dd>
認識的人通常比較不會虧待妳，彼此會有較廣的談價空間。否則，經驗不夠的新手總是比較容易吃虧。比如，對行情不夠瞭解的話在談薪水的時候就就可能變成廉價勞工、技術稱不上專精卻承諾難度過高的功能。在團隊中，這些工作會交給有經驗的專案管理者負責，妳不用去擔心。
</dd>
<p></p>
<dt><strong><a name="item__b6_b6漠的_b7_be_b3q綬_b9d">順暢的溝通管道</a></strong><br />
</dt>
<dd>
熟人之間總是比較好講話，事情可以坦白說而不需要像跟陌生人應對一樣客客氣氣地修飾文字與用語。而且，彼此之間已經有了基本程度的瞭解跟默契，在溝通的時候也相對輕鬆，節省不必要的時間浪費。
</dd>
<p></p>
<dt><strong><a name="item__a6_b3_abe_bdb7鵴u">有前輩照顧</a></strong><br />
</dt>
<dd>
完成一個專案等於是上了一堂作中學的課，在最初的學習過程中有人帶領總比自己摸索要來得容易。參與團隊，一方面妳可以看到完整的專案開發過程，另一方面也可以學習其她人處理事情的能力。萬一出了意外，也會有同伴提供經驗幫助妳把問題解決。
</dd>
<dd>
<p>儘管人際關係幫助妳在開始時候比較輕鬆，然而，也有相對的責任要承擔。前面提過，對方會願意把案子轉介給妳，是基於人情，也是基於信任。如果案子沒做好，影響的不只是妳的個人信用，也會連帶影響到客戶以後對介紹人的信任。除了對客戶難以交代之外，對朋友也說不過去。</p>
</dd>
<dd>
<p>此外，在心態上也要警惕，不要因為有人介紹就以為自己擁有特權。人情並不能永遠幫妳，妳自己的技術能力和表現才是真正讓人評價的地方。</p>
</dd>
<p></p></dl>
<p>
</p>
<h3><a name="1_3_2____發_踆o____">1.3.2. 開發其她案源</a></h3>
<p>在熟悉了接案的基本流程之後，妳就可以開始利用網路找案子了！委外仲介網站是個不錯的開始。就像從求職網站或職業介紹中心找工作一樣。妳登入會員，留下個人資料、專長、欲尋找的工作內容與聯絡方式。公司經由妳填寫的資料幫妳尋找符合需求的專案然後將案主資料寄給妳，同時也把妳的資料寄給案主。或者是，妳可以線上經由網站資料庫尋找妳有興趣的專案與案主資料。</p>
<p>專案的合作細節與雙方交涉的過程，通常仲介公司並不干涉。委外仲介公司只是負責為有發案者跟有接案者提供一個取得資訊的統一管道。</p>
<p>公開網站的徵人廣告與BBS站上求職徵人版也是可供利用的管道。案主會在這些場所貼上專案資料，所需人才能力，若是妳覺得自己適合，可以主動跟案主聯絡，尋求雙方合作的可能性。</p>
<p>既是由委外仲介跟徵人廣告找到的專案客戶，獨立工作者就要有心理準備，所有的溝通、談判、簽約合作等事情都要一把抓。不過，雖然都是要由自己處理各項事情，仲介公司通常為會員提供與專案相關的額外服務。如會員專屬線上討論社群，讓新手可以在上面發問，尋求幫助；法律咨詢信箱幫使用者解決合約上的疑問。此外，仲介公司多了一層過濾的功能，登記的專案案主至少在仲介公司留有資料，比起自己搜尋來得有保障。而有個單一的資訊來源也可以省掉到各個網站跟BBS站收集資訊的時間。</p>
<p>除了被動地在網路上尋找專案外，妳也可以主動出擊，把自己的履歷貼上去，讓別人看到妳。或是評估妳覺得可能有需求的商家，一家一家拜訪推薦自己，告訴店家妳可以做什麼詢問她們是否需要。比如跟餐廳老闆說妳可以幫餐廳架網站做網路宣傳。</p>
<p>自我推銷需要相當的勇氣與行動力，在語言表達能力上也不能太遜色。有些商家或許根本沒考慮到這方面的需求，妳可以跟她們聊天，告訴她這樣做可能帶來什麼潛在的好處。不需要像恐怖的超級推銷員那樣咄咄逼人或勢在必得，妳的行為不過是讓別人瞭解妳所具備的能力，日後當她們有需求時，就有可能會找妳。</p>
<p>除此之外，確定妳周圍的朋友都知道妳現在是個獨立工作者，而且，總是在尋找接案的機會。將接案的收入撥出少部份（如5%）做為仲介費給朋友、請朋友吃頓飯看場電影，或是送份禮物，都是妳表達謝意的方式。如此一來，妳的朋友比較會願意持續積極地幫妳介紹工作。</p>
<p>有可供展示的作品通常能提供客戶對妳的信賴。這些可能是妳曾經寫過的作業、或是閒暇時的即興作品，稍作包裝之後放在網頁上、電腦裡或做成平面檔案。跟客戶接觸的時候可以展示出來，讓她們相信妳是真的有能力。</p>
<p>最後，如果妳是學生的話，還可以從學校工讀找起。學校的計算中心以及各單位的行政與教學部門，都會需要有人幫忙做程式設計或系統維護的工作。像是寫網頁、行政流程自動化程式之類的。多跑各處室詢問或是勤看公告欄，都可以幫妳找到這方面的工作機會。比起外面社會，學校的工作環境比較單純。通常也不需要談合約的手續，工讀生薪水或許不高可是相對的壓力也較小。妳也不用為了案子多花時間在外奔波。在接觸過的獨立工作者中，不少人的第一個專案都是從學生時代在校工讀開始的。</p>
<p>
</p>
<h3><a name="1_3_3___q_蓲__l___l_琯n_o_h">1.3.3. 從哪些案子開始接好呢？</a></h3>
<p>什麼樣的案子適合初學者呢？我們分兩種工作模式來談：參與團隊開發與個人獨立接案。兩者各有不同的考量點。</p>
<p>參與團隊的話，案子的選擇權其實不在妳手上，而是由專案管理者決定。妳要決定的是，什麼樣的工作內容。一個專案的分工通常有專案管理、系統分析，跟實作三個大項。</p>
<p>站在磨練基礎技術能力的立場，新手一般是從實作部份做起，也就是，實際地用程式寫出某些功能。這時候，妳可以思考自己比較想從事哪部份的實作，這個功能或是那個功能。在工作內容的選擇權上，除非證明妳在哪方面的能力特別好，否則，新手很難主動要求別人把特定的什麼部份讓妳做。當然，若是妳來頭大有名氣就另當別論。</p>
<p>專案發展使用的語言與開發工具，可能是妳接觸過，也可能是妳完全不知道的。是否願意為了一個專案去學習新的語言、開發工具和技術，這也是當妳在決定是否參與專案時，所要思考的問題。</p>
<p>若是個人獨立接案，則又另當別論。對沒有實際經驗的新手來講，建議從規模較小的案子做起，因為在剛開始妳需要的是訓練自己的能力跟建立自己的商譽，規模小的案子較容易掌握，出錯的機會也比較小。規模大的案子系統架構通常較複雜，需要足夠好的系統分析設計能力才可以做，這對新手來說，並不容易，也不是一朝一夕之間就能馬上學會的。</p>
<p>接案子不是只要會技術，還要對客戶方的專業領域有瞭解才行。自己一個人的話，剛開始不要接牽涉到太多客戶專業領域的案子。因為在對自己的專業技術都還不夠熟練的情況下，還要去熟悉客戶的專業領域是很辛苦的事。在接案初期，「不懂的領域不要碰」是很重要的守則。</p>
<p>從技術難易程度來看，大部份的人從簡單的網頁設計、Javasript 應用開始。然後是與伺服器端連結的應用程式，如CGI、ASP跟PHP。接著是資料庫相關的規畫、應用程式撰寫。熟練這幾樣技術之後，大多數案子所需要的能力妳就大致都具備了。可以試著去接比較大型的專案，或學習其她領域的知識。</p>
<p>很多知識與能力是由時間與經驗慢慢累積而成的，不需要急著在起步的時候就把所有的東西都學會。盡量抱著學習跟自我磨練的心態，多和有經驗的人溝通，相信妳的接案生涯就能順利的展開。</p>
<p>
</p>
<hr />
<h1><a name="2_____q___f___餩螵_蜤">2. 溝通: 達成最佳共識</a></h1>
<pre>
地點：某工作室
時間：早上10點
「喂」（^_^）
「呀，吳先生你好」（^o^）
「什麼，你說還要開一個討論版的功能」（?_?）
「好呀，沒問題」（^^;）
「啊，還要聊天室」（>_<）
「可是吳先生，你不是要做庫存管理系統嗎…………………」（^_^|||||）</pre>
<p>相信有過接案經驗的開發者都會承認，在開發過程中，最艱難的部分不是在實際開發程式或系統本身，而是在開發時接案者與案主之間對開發內容的協調與認定。案主對於需求常常表達得不夠明確，模糊的需求對於接案者而言，是非常困擾的。案主偶爾的福至心靈，看到或想到他們覺得更好的主意，然後以各種方式，軟硬兼施，想辦法讓接案者乖乖就範，達成更改需求的目的。</p>
<p>不知道案主確實要什麼樣的東西？需求一直變更讓開發變得困難，因為規格一直不停的變更，往往業務方面為要討好客戶傾向接受，而工程師因開發的麻煩而傾向抗拒。就這樣在一來一往之間就把時間浪費時間，結案也總是因為這些不期然的因素不是馬虎交貨不然遙遙無期。相信身為一個接案者，或多或少都曾遭遇過類似的問題，抱怨歸抱怨，問題還是得解決，探究之所以會有這些問題的原因，便是在與案主互動的過程中，沒有充分達成有效的共識，總歸一句話，這些問題的癥結就在於溝通。</p>
<p>有人會說，「那是你們笨，這些東西你們簽約時寫清楚不就好了嗎。」但現實上，契約不是一蹴可及的，契約訂立的任一方，都會想追求自己最大的權利，責付對方最大的義務，這中間不免發生利益衝突，或有疑意不清的地方。這些問題的解決，都必須靠雙方的協調與讓步。「法律是死的，人是活的。」通常法律是最後的手段，往往也是最糟的手段，因為真正動用到法律時，耗時耗財，最後的結果常常是得不償失。「簽約」事實上只是表達雙方合作的誠意，並將溝通的結果載明於文件上。因此，真正大部份問題的解決與預防，還是得靠事先良好的溝通。</p>
<p>溝通的目的在於明確表達案主及接案者雙方的想法，達成雙方均可接受的共識，讓雙方的認知一致，以減少因誤會而導致的各種沉沒成本，避免開發過程中雙方投注大量的心力，卻開發出無用或不適用的成品。溝通不良或認知不一致除了影響開發的時程，也將影響開發的品質，更甚者，將導致案主與接案者感情的破裂，不但案主心疼白花錢，自此不信任外包，造成外包市場規模的縮小，對接案者而言，除了浪費時間及滿肚子怨氣之外，也有可能因此一案而砸了品牌，沒了形象。</p>
<p>溝通在專案執行過程中的重要性可見一般。然而，由於溝通是一種人與人之間互動的方式，溝通的成效僅能用結果來衡量，沒有所謂的定理存在，只有經驗的傳承與累積，前人種樹顯得格外偉大。如人飲水，冷暖自知，有了這些笑淚交織、活生生的經驗所整合出來的一般性原則及建議，最多也只能提供接案者殷鑑不遠的參考，真正有效的溝通只能透過接案者的親身體驗而進一步內化成自己的葵花寶典。</p>
<p>以下這章是專為獨立工作接案者或者是工作團隊的接案代表（簡言之，就是業務）而寫的，主要談的是如何對你的案主（也就是客戶）進行溝通，第一部份談的專案溝通時一些基本原則，是適用整體專案流程，接下來談個別階段的溝通，從事接案前的接觸、溝通、訂價、規格到進行時狀況及結案動作，我們會有一系列完整的介紹。如果你是個菜鳥，這章你應好好細讀，如果你是個老鳥，可以對照一下自己的經驗。</p>
<p>
</p>
<h2><a name="2_1___m_____q的_瀖__餩h">2.1. 專案溝通的基本原則</a></h2>
<p>溝通在字面上的意義是雙方資訊及意見的流通，事實上，溝通包括兩個層面，一個是議價能力（Bargaining），一個是協調技巧（Negotiation）。在專案流程的溝通中，兩者往往交互使用的過程。你的議價能力取決於你本身的條件，而你的協調技巧取決你的臨場做法。</p>
<p>通常而言，議價能力直接影響到最終的價碼；議價能力較強的一方，通常可取得價錢優勢，相反的，議價能力弱的一方，通常在價錢上就只能乖乖的配合，否則就做不成生意。對接案者而言，議價能力的大小取決於個人技術能力的強弱、個人品牌知名度的高低以及個人接案形象的優劣，這些都是靠以往工作經驗的累積。倘若接案時案主知道他所找的接案者其技術能力夠強，知名度夠高，過去的開發成果具有一定的口碑，則在進行專案溝通之時，便較能獲得案主的尊敬及信任，進而使得溝通的進行較為順利。因此，一個成功的接案者在平常就必須好好的經營自己，累積自己的技術能力，建立自己的名聲與專業形象。
至於協調能力則與專案工作能否順利完成有關，一個協調能力好的接案者，會迅速判定誰是主要的溝通對象，以專業、誠懇的方式與案主進行洽談。在洽談的過程中能科學地分析客戶的需求，給予適當的建議，並能引導接案者接受自己的想法，避免可能爭議的發生而非等到爭議發生時，再將爭議平撫下去。</p>
<p>我們常聽到一句老話「預防重於治療」，最好的溝通，並不是指在衝突發生時能調和鼎鼐，折衝樽俎，而能夠針對進行狀況可能發生的問題，事先規範，避免日後爭議發生。因為，等到爭議發生時再處理，不論最後的結果如何，至少有一方認為自己吃虧，進而影響下一次合作的機會。所以，在一般委外專案中，不論有理無理，往往是接案方步步退讓，儘量滿足案主的需求，理由就是他不想破壞下一次的合作機會。</p>
<p>
</p>
<h3><a name="2_1_1___n_趌o">2.1.1. 技術能力</a></h3>
<p>具有一定水準的技術能力不但可讓接案者在與案主溝通時具有相當程的自信，也能夠迅速理解案主所提出的功能需求並判斷各項需求的的可行性。技術能力除了可提供接案者評估是否接受專案委託的標準，在溝通的過程之中同時也是案主評估是否外包給接案者的考量因素之一。</p>
<p>技術能力可由技術的深度及廣度來衡量。所謂技術的深度是指對特定某項技術的專業程度，舉例而言，某位接案者對Java語言特別熟稔，可提供案主Pure Java的Solution；或是某位接案者對於多媒體技術特別擅長，可提供案主效果最好的即時影音播放（Real-time）或是隨選視訊（VOD）的Solution。</p>
<p>技術的廣度則表現在接案者對於某項領域技術的專長。例如某位接案者對於各種資料庫都頗有研究，從Oracle、SUN到MySQL，均有相當程度的了解，可提供案主資料庫相關的整合應用或資料處理的Solution；或是某位接案者對於各種HA（High Availability）的技術均十分熟悉，可提供案主關於流量分散或是容錯處理的系統設計建議。</p>
<p>面對具有技術背景的案主，接案者的技術能力更是不容輕忽。技術能力代表的是接案者是否有能力可以接受專案開發的委託，代表的是案主是否可以信任接案者而將開發的重責大任交付給接案者。愈具有技術深度及廣度的接案者，愈能受到案主的尊敬及信任，在溝通過程之中除了可以減少因不信任所增加的額外成本，也可提高溝通的效率及效果。在與案主協商的過程中也較有立場或地位堅持一些開發的基本原則，在開發前即確立開發需求，並適當的拒絕案主不合理的需求變更要求。</p>
<p>
</p>
<h3><a name="2_1_2____皖泣_w__">2.1.2. 品牌知名度</a></h3>
<p>品牌知名度，指的是接案者在外包市場上具有某種程度上的名氣，這個名氣可能來自於接案者參與實際開發的技術能力，也可能來自於接案者在某個技術領域上的專業性與權威性。舉例而言，某個接案者曾參與研發過頗具代表性的無線網路應用技術，在無線通訊領域中享有盛名；或是某個接案者是開放原始碼（Open Source）產業的推動者，在開放原始碼領域中具有特殊的領導地位。這些接案者在特定領域中就像明星般具有高度的知名度及影響力。</p>
<p>不管任何行業，身價和名氣是呈正相關的，因此你想要提高工作的報酬及可信度，「成名」是個值得努力的方向。當然，要成為家喻戶曉的大人物是有點運氣的，不過至少你該應努力經營自己。想辦法取得一些證照來證明自己的實力。</p>
<p>通常而言，證明自己的實力方式有下列三種：</p>
<dl>
<dt><strong><a name="item__a4鼁�">比賽</a></strong><br />
</dt>
<dd>
通常分二大類，一是網頁設計比賽，另一種是程式設計比賽。前者機會比較多，不止學校，像企業也會舉行類似比賽，例如像友立為了推廣PhotoImpact，就有舉行網頁設計比賽，社會人士也可以參與。後者多偏在學校、內舉行。不管什麼比賽，如果你能得名，把獎狀印一印，這張紙將是顯示自己能力一個有力的證明。
</dd>
<p></p>
<dt><strong><a name="item__bb_7b蜚">認證</a></strong><br />
</dt>
<dd>
各類軟體公司為了推廣及軟體都會有一些認證，如微軟認證（MCP，Microsoft Certified Professional，最主要是MCSD，Microsoft Certified Solution developer）、Java認證等等，證明你在這方面確實是一個專家，有了這些大公司的保證與背書，對客戶而言，心理上會覺得交給你來做，比較有保障。
</dd>
<p></p>
<dt><strong><a name="item__a7_40_ab_7e">作品</a></strong><br />
</dt>
<dd>
這是最實際的東西，給客戶看你所做的作品，好作品的說服力遠比比賽與認證還有用。但唯一不同的是，在初期而言，比賽及認證資格比較容易提高你身價（因為有市場行情），好的作品則很難，但是作品可以大幅提高客戶對你能力的信任。
</dd>
<p></p></dl>
<p>儘管你是一個自由接案者，但接案和應徵工作並沒有什麼兩樣，要好好準備自己的履歷，告訴你的案主你做過什麼事，甚至包括被什麼單位應邀演講之類的，這些都是增加自己可信度的重要條件。但要注意一點，要針對不同的個案要好好強調你相關工作「技術」經歷與背景，對案主而言，他們才不管你當幾年的獨立接案者；事實上，案主根本希望你是一個商業白痴，但是他們會十分在乎你的專業工作能力。</p>
<p>具有品牌知名度的接案者，在議價能力上便具有相當程度的優勢，所提出的言論或建議也具有某一程度上的可信度，在與案主溝通的過程中，在一開始即可因接案者的知名度而省下不少相互摸索的成本，由於案主早已知曉接案者的專業技術及名聲，因此毌須重新認識或調查接案者的背景及能力，而接案者也可減少推銷自己的時間成本，一開始與案主洽談即可直接切入主題。</p>
<p>一個具有品牌知名度的接案者，就像一個擁有許多專業相關人士背書的技術開發者，可以讓案主放心的將專案委託交付，相較於一般的接案者而言，也可具有較多的接案來源，進而累積更多的開發經驗。身為一個在特定領域中具有品牌知名度的接案者，通常也會因為該領域的人脈擴展而有較多的經驗分享機會，在良性循環中累積創造自身的價值。只要曾經有過參與某個技術社群的經驗，相信便可深切體會到社群所創造及分享的力量，那些技術社群裡的意見領袖，在在可做為具有品牌知名度的接案者代表。</p>
<p>由品牌知名度所帶來的效益，除了降低初次的溝通成本之外，也使得接案者在與案主洽談時，能夠具有較為平等的地位，在協商過程之中也較易能夠維持某些基本的權益。</p>
<p>
</p>
<h3><a name="2_1_3___螵h_螵f_o">2.1.3. 形象及口碑</a></h3>
<p>接案者過去接案的成果，是接案者彰顯自己能力的最佳證明。良好的配合度、順暢的互動過程、傑出的技術能力以及完備的開發成果，均是案主在衡量合作對象時的重要指標。具有良好形象及口碑的接案者，等於有了免費的宣傳工具，藉由輿論的口耳相傳，可帶來較多的委託需求，進而增加許多的選擇機會，讓溝通時的議價能力提升。</p>
<p>形象及口碑是接案者有力的背書，透過形象的建立及口碑的宣傳，可讓案主對接案者具有較佳的初次印象，如果介紹者或引介者是具有相當地位的人士，如案主的朋友或是技術專家，則接案者將可獲得案主相當程度的信任及尊敬，在專案開發的過程中也可獲得較大的自主性。</p>
<p>以上所提到的這些個人優勢，可以創造出一個對接案者較為有利的溝通環境，然而，要達成有效的溝通，尚需佐之以高明的談判與溝通技巧，以及對一些溝通細節的掌握及注意。牢記溝通的目標在於協調雙方認知的一致性，時時提醒自己在溝通時是否忽略了某些重點，而這些疏失足以影響未來開發以及驗收的進行。</p>
<p>
</p>
<h3><a name="2_1_4__表___m__">2.1.4. 表現專業</a></h3>
<p>要建立別人的信任感，表現「專業」是第一要素。特別是對素未謀面的案主，在一開始，他唯一評判可以的標準就是你的行為表現。要記住，雖然你的客戶不會寫程式，也許連電腦也不會用，但是這些人大都有一定的社會歷練。因此如何讓他感受到一你是一個箇中老手，有能力達成他的工作任務，是一件很重要的事。一個表現不專業的人，基本上很難贏得信任，你很難接到案子，如果接到了，價格也無法提高，並且花在與案主溝通的時間上會比你做事情的時間還多，因為你要對一個不懂技術的案主，花費許多口舌去解釋為什麼那麼做，以取得他的信任。</p>
<p>儘管人家說「內在比外在」重要，但佛要金裝，人要衣裝。拜訪案主時，適當的衣著是很重要的。同樣是學生，一套西裝可以馬上提昇你的社會年齡，常有學生團隊穿著夾克，午仔褲，球鞋就去見客戶，這樣的印象馬上就暴露自己的身份；相同的道理，如果你是穿著金金亮亮全新的阿曼尼西裝出席，太過隆重，也會犯了相同的毛病，都是向你的客戶傳達一個訊息，「我是新手上路」，這種人通常是從此不再聯絡，不然就是當待宰羔羊，任人宰割。當然，西裝不是唯一選擇，你也可以學習蘋果電腦總裁賈伯斯高級襯杉加牛仔褲的穿法，畢竟你是技術專業人員，而非服務業從業員，服裝上沒有職業性講究，唯一的原則就是挑一些成熟一點的衣服，顏色不要花綠，記住，千萬別穿球鞋。不可諱言的，建立專業形象是要花點銀子的，你不必花大把的鈔票花在這上面，但適度的投資顯然是必要的。</p>
<p>當然，適當衣著只能抵擋客戶銳利的評審眼光五分鐘而已，你的動作談話仍要得體，不然一下子黔驢技窮，可是馬上會被老虎吃掉的。至於要不要有名片？我的建議是最好能夠有，但如果你是獨立作業，沒有也什麼關係。名片的好處是可以節省對方抄寫你聯絡方式的時間，當然，如果有Palm可以交換一下相互的名片檔也是不錯的選擇，在拜訪的一開始，如果能順勢向客戶討教一張名片，通常可以從名片上了解對方的基本背景，例如公司名稱，客戶的職稱，進而判斷如何與其溝通。</p>
<p>你能帶著NoteBook或者作品資料向你的客戶簡報你以往的工作經驗，及能夠有系統的詢問對方的工作需求，那就更優了。資料作品可以客觀的佐證你的專業能力，這點不證自明，無需贄言。那什麼是有系統的詢問呢？簡單來說，就是有點像填表格的文件，除了基本資料外，你會細詳性詢問他的要求，例如先確認一下客戶公司使用的電腦硬體及作業系統（相信我，還有公司是在用486配合DOS系統在作業），然後再確認公司目前使用那些軟體，是否有Database系統或者是財務管理系統存在（考慮到資料銜接問題），及公司目前上網的情形（Moden，ISDN、ADSL或專線），最後再針對上述的狀況提出說明及你的看法。</p>
<p>這樣有系統地分析出客戶目前狀況會顯得你的接案經驗豐富；就算你事實上沒有足夠的實地經驗，參照別人的經驗，能夠組織性詢問客戶或介紹自己想法，會增加你的權威感。如果能夠事先得知客戶公司或個人的基本資料，花點時間加以研究，並且在談話表達一下對相關看法（當然是正面的），都有助於與客戶溝通，提昇客戶的信賴感。</p>
<p>
</p>
<h3><a name="2_1_5__榮___�">2.1.5. 態度誠懇</a></h3>
<p>儘管溝通是門藝術，需要經驗的磨鍊，但這也絕不表示在溝通時你應該表現的像隻老狐狸一樣的與你的案主談話，要知道通常你所面對的案主大都是有一定社會經驗的人，如果你不誠懇或想裝腔作勢，事實上，馬上會被識破的。</p>
<p>誠懇並非坦白，但也絕非欺騙。懇誠是顯示你很有誠意去爭取這個客戶，並且在溝通的過程中突顯自己的優點，儘量去避免提及自己缺點（如自己接案經驗不足），除非自己的缺點將會導致無法完成客戶所交付的任務（自己明明不會Linux，硬說自己會）。如果客戶發現你的缺點時，「小伙子，你是第一次出來接案吧！」你也不妨緬腆一笑，大方承認，反而會博得對方的好感。</p>
<p>前面說過，案主通常是不懂的IT技術的人，因此在與其面談時，絕對不讓客戶覺得自己很笨，儘量以案主的角度及語言去解釋，不要露出瞧不起人，你不懂技術，或是連這個你也不知道的態度。在溝通的過程中，絕大部份的案主會因不了解電腦或網路而會問許多非相關專案的問題，例如，如何收E-mail，Outlook要怎麼使用等等，此時，千萬別在語言中透露出你的不耐。另外，在解釋時請儘量白話，少用專業術語。要記住，他們生長的世代與你不同，許多IT產業的四、五十歲高級主管在通E-mail用英文，理由不是他們留過洋喝過洋墨水，所以愛用英文，而是因為他們不懂中打。</p>
<p>
</p>
<h3><a name="2_1_6___踆麊榕h___q">2.1.6. 找對的人溝通</a></h3>
<p>在接案的過程中，接案者要能迅速地判斷你所面對的客戶代表是不是具有拍板定案的權力，這點非常重要。畢竟，談案子的目的是要求個結果，能談成是最好，如不能配合，早聚早散，將時間好好準備下一個案子也是不錯。而且，公司內部隨著決策位置不同，往往對事情的要求也不一樣，客戶代表說的，往往和真正客戶的要求會有所差異，因此趁早弄清出誰是具有拍板定案權力的代表，直接直搗黃龍，容易事半功倍。</p>
<p>但是，這不代表你就可以忽略一開始的客戶代表，畢竟沒有他們的推薦，你是無法見到幕後大老闆的。但如果和客戶代表談了二、三次還沒有見到真正決定者，那麼你就要小心，也許你只是成為客戶代表比價參考的對象而已。另外，客戶公司裡的其他人也要注意，特別是客戶裡的IT方面的主管，因為客戶本身也會想聽聽自己人的意見。通常，這類的人對你案子是「成事不足，但敗事有餘」。基本同行相輕的心理上，他們對外來接案者在態度上會比較敵對，除非你本身是由他們所推薦的。</p>
<p>另外，為了確定溝通管道正常，過濾發案方內部的要求，避免雜音干擾，或重覆要求，在大型專案中，合約中可以指定發案方與接案方的聯絡人，一方面可以明確責任，一方面也可以保障溝通訊息正確。</p>
<p>在商場上，難免會碰到一些不講誠信的人，如何判對一個人誠信與否，是需要經驗累積的，這樣的過程是只能意會不能言傳的。但是這裡可以提供一個經驗法則是：不要被對方的外表或態度所矇蔽，唯由行動才能判定一個人的誠信。根據經驗顯示，所謂是騙術家，往往是最親切的人。無論你的合作對象態度再好，一旦沒有依約按時履行義務，你就必須小心注意。</p>
<p>
</p>
<h2><a name="2_2___m___騶潷e的___q">2.2. 專案執行前的溝通</a></h2>
<p>在專案正式簽約之前，大約可以分成洽談、需求分析、訂價、正式提案等四個階段。這張表列出了各個階段的要點及溝通內容：</p>
<pre>
+------------+----------------------------------+----------------------------+
|專案執行階段|內容 |要點 |
+------------+----------------------------------+----------------------------+
|洽談階段 |溝通內容：初次見面，請多多指教 |* 了解案主的基本資料 |
| |溝通目標：爭取接案機會 |* 思考或草擬解決方案的想法 |
| |溝通結果：口頭或意思表示進入需求 |* 不要做超過自己能力的承諾 |
| | 分析階段 |* 引導案主說出需求 |
| | |* 提供案主可能解決方案 |
+------------+----------------------------------+----------------------------+
|需求分析階段|溝通內容：基本需求 |* 以圖文說明輔助溝通 |
| |溝通目標：了解案主的基本系統及 |* 適度的幫案主釐清需求， |
| | 功能需求 | 而非幫案主規劃需求 |
| |溝通結果：基本提案書及報價 | |
+------------+----------------------------------+----------------------------+
|訂價階段 |溝通內容：系統開發報價 |* 了解行情制定合理價格 |
| |溝通目標：配合正式提案確認價格 |* 溝通重點應放在替客戶「解決|
| |溝通結果：正式合約 | 問題」和「滿足需求」，而非|
| | | 價錢本身。 |
| | |* 試著提出二種以上報價 |
+------------+----------------------------------+----------------------------+
|正式提案階段|溝通內容：系統開發內容 |* 於正式提案書內確實載列專案|
| |溝通目標：配合報價，向案主確認 | 的各項系統功能 |
| | 開發內容 |* 於系統開發時程規劃書中規範|
| |溝通結果：正式合約 | 系統開發時程 |
| | |* 以 Prototype 呈現系統全貌 |
+------------+----------------------------------+----------------------------+</pre>
<p>
</p>
<h3><a name="2_2_1_____燲__q">2.2.1. 洽談階段</a></h3>
<pre>
* 溝通內容：初次見面，請多多指教
* 溝通目標：爭取接案機會
* 溝通結果：口頭或意思表示進入需求分析階段</pre>
<p>洽談階段是指案主與接案者最開始的接觸期。雙方接觸的方式有可能為案主透過查訪或有人引介而主動聯絡接案者，也有可能為接案者透過管道得知案主有系統委外需求而自動毛遂自薦，或是雙方透過仲介者相互聯絡到對方。</p>
<dl>
<dt><strong><a name="item__a4f_b8鎕ae_d7_a5d的_b0瀖a5_bb_b8獥ae�">了解案主的基本資料</a></strong><br />
</dt>
<dd>
初次見面最重要的是第一印象，接案者在與案主聯絡見面之前，最好能夠先了解一下案主的背景，包括公司的基本資料，發展動態，未來方向等，這些資料可由公司網站，新聞稿，朋友或是報章雜誌取得。所謂知己知彼，有了這些消息做基礎，不但有了與案主的閒聊話題，接案者也可因了解案主的基本資料而較能切入問題核心以及案主的實際委外需求。對案主而言，也將會對接案者的認真負責與勤作功課而印象深刻。
</dd>
<p></p>
<dt><strong><a name="item__ab踆a6瀖a9螵af鶆趌b8鎕a8m_a4醂ae_d7的_a4_40_a8蓲b">思考或草擬解決方案的一些想法</a></strong><br />
</dt>
<dd>
除了案主相關的基本資料外，預先針對案主所提出的一些需求作準備，在與案主見面之前對這個案子的難度、開發時間、開發方式……等問題先在心裡有個譜，在與案主溝通時，將較能掌握案主所要開發的系統全貌。切記千萬不要期望案主在第一次見面時即將需求非常明確的表達出來，案主通常會透過與接案者的溝通過程而將需求明確化，因此事先預作準備可以輕鬆的應答案主所提出的相關問題，也可藉此建立案主對自己系統開發能力的信任度。
</dd>
<p></p>
<dt><strong><a name="item__a4_a3_adn_b0琯b6w_b9l_a6a4v_af趌a4o的_a9醭bf�">不要做超過自己能力的承諾</a></strong><br />
</dt>
<dd>
身為一個系統開發者或程式設計師，常常存在著一種使命感，就是要開發出一套當下最完美的系統。對於案主所提出的需求概念，接案者往往有許多解決方案，甚至還想出更棒的點子。通常這些很棒的點子是可以開發出來的，但重點是需要花費多少的時間及成本，接案者必須仔細衡量自身的時間及成本限制，千萬不要不管案主提出什麼樣千奇百怪的需求，均拍著胸脯保證絕對可以達成，之後卻耗費大量精力在研究及評估開發方式及可行性。做超額的承諾一開始可能可以獲得案主的讚賞，甚至獲得開發委託，但在實際執行時卻將面臨將花費大量時間成本的問題，倘若無法達成，更會影響接案者本身的形象。
</dd>
<p></p>
<dt><strong><a name="item__ae_d7_a5d_bb_a1_a4_a3_b2m_b7_a1_ab蓲bb瀖bf�">案主說不清楚怎麼辦</a></strong><br />
</dt>
<dd>
要知道，所謂的客戶大都是非專業人士，他們通常只能說出一個模糊的形象，並且以為你就能馬上化腐朽為神奇，完美地的呈現在他們眼前。因此適當的引導與事先的說明是很重要的。以成品的「修正」問題為例，這是幾乎每一個接案者都會遇見的問題，不論是做程式還是做視覺的，都會有此困擾。特別是做美工視覺的接案者，畢竟每個人的美感經驗不同，只能意會，無法言傳。相同地，追問這個問題產生的原由，絕大部份的接案者會說，問題的發生是在於「案主並沒有事先明確告知其想法。」面對此一情形，你可以去引導他：問他有無偏好的網站？或者將他的要求轉換成規格化的術語說出來：你是指要設一個E-mail伺服器？重要的是要以你的專業知識去引導他「自已」說出想要的形象。
</dd>
<p></p>
<dt><strong><a name="item__a6p_a6醭a9_b4_ae_d7_a5d的_b4_a3踆b3">如何拒絕案主的提議</a></strong><br />
</dt>
<dd>
要記住，案主找你是為解決他的問題，而不是花錢買教訓。在接案溝通時，切忌去否定客戶的想法，這一個很重要，絕對不要脫口而出說：「做不到。」不管有心無意，此話一出口就代表兩個意思：一是自己能力不行，二是案主的要求太過份，這是對案主和自己的雙重否定。是最差的溝通詞句。不管理由為何，如果你想勸案主打消主意，而是應該從案主本身的立場，從你「專案」的眼光幫他分析：如這總做法會超出預算，或者是會讓使用者失去耐性，或者不利員工的工作習慣… 等等的理由，反正是站在案主的角度方式去勸說才比較容易溝通。
</dd>
<p></p>
<dt><strong><a name="item__af_b8_a6b_ae_d7_a5d的_a5絻b3騶a5h_ab踆a6�">站在案主的立場去思考</a></strong><br />
</dt>
<dd>
在提出解決方案，儘量不要加入個人的偏好，如硬體上我就是要用SCSI架構，或者非用Linux Solution不可。在解決問題的前提下，通常案主的考慮有幾項，一是預算，二是否能銜接舊有資料，三是使用習慣，四是維護問題。所以，在早期溝通時，如果能對上述幾點做成不同案子的分析，會令人印象深刻。就算現實情形是自己只擅長單一的架構，但是在向案主溝通時，針對上述幾個項目做出說明，將你所推薦的架構包裝成較好的方案。
</dd>
<p></p></dl>
<p>
</p>
<h3><a name="2_2_2___d_鄋r___q">2.2.2. 需求分析階段</a></h3>
<pre>
* 溝通內容：基本需求
* 溝通目標：了解案主的基本系統及功能需求
* 溝通結果：基本提案書</pre>
<p>初次見面後，如果雙方均有意願繼續進行下去，則進入需求分析階段。需求分析階段主要的目標在於根據案主所提出的基本需求，提出一份簡單但完整的基本提案書，一方面將案主需求具體化，供案主釐清需求，另一方面接案者也可藉以確認是否有誤會案主關於整個系統的想法。如果有不只一位接案者競逐開發機會，則基本提案書尚可做為案主衡量評選接案者的參考。</p>
<p>需求分析階段視案主需求的明確程度而有不只一次的溝通機會。</p>
<dl>
<dt><strong><a name="item__a5h_b9駻a4嬅bb_a1_a9bb_b2_a7u_b7_be_b3q">以圖文說明輔助溝通</a></strong><br />
</dt>
<dd>
基本提案書要儘量具體完整表達出案主所提出的需求，除了文字描述之外，最好佐之以圖形說明。舉例而言，在提到介面功能時，除了列舉說明外，如果能加上功能之間的架構運作圖示，將有助於表達各個功能呈現的樣貌。
</dd>
<dd>
<p>基本提案書沒有一定的撰寫方式，主要的目的在讓案主能夠以書面的方式輕鬆了解需求具體化後的成果，由於每個專案的性質及大小不一，因此基本提案書的架構需視專案需求而做適當的調整，一般基本提案書所會提到的重點有：</p>
</dd>
<p></p>
<li></li>
前言：簡單說明這個系統規劃的目標或目的。
<p></p>
<li></li>
介面功能規劃：先依主功能分項，再按介面動線描述該主功能項下的各細部功能。這是使用者所看到及所使用的功能。
<p></p>
<li></li>
系統功能規劃：所有介面功能背後都有相關的系統功能，此章節即在按系統功能項目分類，逐項描述各系統功能項下的細部功能。這是系統管理者所看到及所使用的功能。
<p></p>
<li></li>
系統架構規劃：簡單說明開發本系統的軟、硬體規劃，如開發平台、相關程式語言、資料庫及整體系統架構的設計。
<p></p>
<li></li>
開發團隊：說明開發本系統所須花費的時間及人力。
<p></p>
<li></li>
開發時程規劃：說明開發本系統的階段性時程規劃及各階段雙方相互應配合的事項及方式。
<p></p>
<li></li>
簡單報價：按功能項目逐項報價。
<p></p>
<li></li>
版權聲明：聲明本基本提案書的著作權。
<p></p></dl>
<p>其中介面功能規劃為案主需求具體化的呈現，系統功能規劃為系統因應介面功能所須配合開發的項目。</p>
<dl>
<dt><strong><a name="item__bea_ab_d7的趌b0_ae_d7_a5d瞀_b2m_bba8d_a1a_a6醭a">適度的幫案主釐清需求，而非幫案主規劃需求</a></strong><br />
</dt>
<dd>
前面說過，許多案主常常只有一些模糊的概念，並未對專案的需求有很明確的規劃，因此希望接案者可以針對一些需求大綱，為案主提供明確且可行的建議。對接案者而言，提供建議不啻是一個彰顯本身能力的機會，案主在佩服欣賞之餘，也可建立對接案者的信任度及認同感。
</dd>
<dd>
<p>但需注意的是，案主是否有誠意與接案者進一步合作，還是只是希望藉由與接案者的溝通及互動，來獲得原來需求不清楚的答案。有些案例即是如此，當接案者興致勃勃的提出各種建議及規劃，案主了解之後，發現可以自行開發，或是最後卻委託其他接案者來開發，結果接案者只有白白提供苦心的規劃，到頭來卻一無所得。</p>
</dd>
<p></p></dl>
<p>有一人得標，其他人落馬，這是參與標案必須有的心理準備，基本提案當然要規劃的完善，才有機會在多人競標的場合中勝出。然而何謂完善的提案﹖過與不及均非好事，這需要適當的拿捏。接案者可以藉由與案主討論需求的過程，觀察案主的心態及誠意，最好是針對案主本身所提出的需求來做基本提案書的規劃，如遇不明確的需求，則羅列不清楚的問題，向案主尋求解答，由案主自己來思考並提供答案，切記提出需求是案主的責任，接案者最好不要幫案主規劃需求。</p>
<p>這裡所指出的是接案者在提出基本提案時可能遭遇的問題以及一般性原則上的建議，並不是絕對的執行方式，接案者可以視與案主的互動狀況或是專案性質而定，如果必須幫案主規劃或建議需求，則接案者也可以利用其他彈性的方式，來保障自己的規劃被不當的剽取，例如透過合約的擬定或是收取部分的諮詢費用等。</p>
<p>
</p>
<h3><a name="2_2_3___q_鸐__q">2.2.3. 訂價階段</a></h3>
<pre>
* 溝通內容：系統開發報價
* 溝通目標：配合正式提案，確認價格
* 溝通結果：正式合約</pre>
<dl>
<dt><strong><a name="item__a6p_a6醭adq_bb�">如何訂價</a></strong><br />
</dt>
<dd>
人生在世，錢不一定萬能，但沒有錢卻萬萬不能。一個人之所以願意離開公司體制，進入沒有固定月薪保障的自由接案者生涯，最大的吸引力之一就是「報酬」。因此你的訂價策略將會攸關未來生活品質與心情。但是開高了，可能會嚇包客戶，開低了，可能會苦了自己。那麼你會如何訂價呢？以美國的例子而言，基本是以時薪計算，其他實體開銷另計。基本上他們收費的原則是先預今年合理薪水是多少，如果是七萬美元，那麼他一個小時就會收七十美元。
</dd>
<dd>
<p>對照到台灣而言，接案者工作薪酬市場的價格是一片混亂，並沒有明確的市場行情資訊可供參考。建立一個網站，有人從五千元到五百萬元的價格都有，當然這還牽扯技術的難度及規模的大小。就算是一個相同規模的網站，其價差的範園依然很大。不過，時間一久，所謂的價格慢慢的也有行情出現。但是這中間還有層次的差異。決定價格差異性因素包括，接案者的性質（兼職的學生團隊和全職專業的價格當然有差），技術難度（做HTML、ASP、JSP及PHP都有不同），是否個人化（專為案主設計的原件），趕工要求等因素，有所不同。</p>
</dd>
<dd>
<p>以價格比較公開化的網頁視覺設計而言，都常如果是找學生或個人來做的，首頁的價格（不包括Flash動畫功能）平均價格約在五千元上下，便宜的，有人喊三千，也有人喊七八千，當然視接案者的能力（如是否得獎，曾做過大型網站）及案主的要求而定。內頁的部份通常是首頁價錢的一半，甚或更低。如果是找專業公司，或美術工作室，製做首頁的價格可能再高，八千至一萬應是行情價，再高的也有，其餘的價錢如上述。</p>
</dd>
<dd>
<p>至於做後端程式的部份，價格就比較混亂。但對接案方而言，評估成本的方式通常是事先評估工作人數及其工作時數。通常難度愈高或愈煩雜的技術，所耗的工作時間愈多，「天」應是計算的基本單位。台灣一個合格程式工程師一天（指工作八小時）的薪水是三千元，依這個為基礎，再參照其他因素，如稅賦的問題，技術權利是否買斷，是否為臨時趕工，再加上你其他開銷（如送機器，架網路線），最後加上利潤參數（就是純粹利潤空間）所決定出來的就是價格。</p>
</dd>
<dd>
<p>以上是現行專案基本開價的算法。在以往，很多接案者會對案主以數量的方式來計價，尤其是網頁設計工作。不過，現在絕大部份的接案者在面對案主報價時，都是以一個案子來計算，連同其他的開支價格如硬體支出部份，合併報價。理由很簡單，這樣比較有利潤，在一方虧的錢，可以在另一方要回來。不過現在市場現實是，台灣有愈來愈多的年輕接案者投入這個市場，因此這行競爭十分激烈，價格上也拼的很兇，但所幸的是，相對的市場需要量也十分龐大。對一個聰明的接案者來說，除了要增加更多附加價值外（如維護），在開發時一定要能建置模型化的工具，換言之，你所寫出的網站程式或素材，一定要能重複再利用。如此才能真正的創造出利潤空間。</p>
</dd>
<p></p>
<dt><strong><a name="item__bbp_ab醂a4塺b3鱌bb�">與客戶報價</a></strong><br />
</dt>
<dd>
通常在你了解客戶的需求及估算你大概的成本後，接下來就是對客戶進行報價。無論你一開始想應該賺多少，都只是空中樓閣。這裡的價格才是你真正的報酬。
</dd>
<dd>
<p>很多人誤以為和客戶談價格是一門很重要的臨場技巧，事實上並非如此，等到你與客戶實質報價的那一天，價格談判的實質意義已經不大。客戶能給你的報酬，早在一開始雙方接觸就已可以推測個大概，這些都歸因於前述你的技術能力、品牌知名度和客戶本身的需求。試想，一個專找學生團隊的客戶，基本上就是抱著「便宜又大碗」的心態，不言可喻，價格是愈低愈好。但是一個一年要做五千萬生意的客戶，那麼價格也許不是重點，重點是你的服務品質是否能達到他的需求，也許是要介面方便，也許是要系統穩定等等要求。真正決定成案價格的最主因素，是接案者對客戶的需求的了解。因此，如果你真想賺大錢，也許一開始，你就應該選好你的市場定位，鎖定你的目標客戶，而非利用客戶的無知企圖想海削一筆。</p>
</dd>
<dd>
<p>回歸正題，報價溝通的重點應放替客戶「解決問題」和「滿足需求」上，而非價錢本身。在報價單遞出去的同時，上面明細列的不應該是你用了多少個工程師每人收費多少。比較好的報價方式是，在通盤了解客戶的需求後，而是根據他的要求，你會提供什麼樣的服務，每項服務多少。試著去區格化你的服務項目，準備出二，三種以上的報價，讓客戶選擇。除非你是採低價戰術或客戶要求，否則在進行報價溝通時，不必刻意強調你的價錢多有划算，或者一項一項算給他看我這樣做的成本是多少，這樣只是提醒客戶去斤斤計較你的價錢。對客戶而言，找你的首要目的是在解決問題，而不是製造更多的麻煩，價格是次要考量。</p>
</dd>
<dd>
<p>當然做生意難免碰到客戶殺價的情況，但如果你開的價錢會被客戶猛砍，這也許證明你溝通不夠，不了解你的客戶需求或事先的預算。如果並非如此，而是客戶不了解狀況時，經過溝通還是無法改變客戶的心意，那麼就放棄吧。一來，如果用過低價格接下這件案子，將會對不起僱用你的其他客戶；二來，客戶會負擔相當的風險，畢竟要另起爐灶，又會浪費一段時間成本，也許倒頭來並不划算。不過，假如你覺得這件案子是關鍵性案件，譬如你的第一件案子，或者是簽了這個案子後，其後將有長期穩定的案源，或者日後的維護性收益極高。如果你判斷是屬於關鍵性案子，價格方面不妨讓步。</p>
</dd>
<dd>
<p>當然在實際商場運作上，也有不同的行銷手法可以學習。台灣許多軟體公司事實上是搭配者IBM和Sun的機器，當他們的軟體支援商過活。因此也有很多軟體公司仿照這種手法，利用賣硬體的手段，將自己軟體包裝進去，例如採購一台伺服器電腦加四台PC一共十五萬元，送網站、E-mail Server等等。也有的是因為案子價格夠高，會直接買台新電腦，將軟體灌好就免費送給客戶。畢竟，對傳統客戶而言，他們會比較相信硬體而非軟體。</p>
</dd>
<p></p>
<dt><strong><a name="item__a5i_b4a4醂a6_a1_bbp_bd禬b4�">付款方式與請款</a></strong><br />
</dt>
<dd>
當案主同意接案者的報價時，通常很快會進行正式簽約，以便早日完成工作。當簽約時，通常會詳述付款方式。通常付款時間，依各家習慣不同，依工作時程分為二次到五次不等，如以三次為例，通常是簽約付三成，完工付三成，驗收結案付四成。至於付款方式則會明定如現金匯入帳戶或開立一個月內對兌之即期支票。偶爾廠商會因現金調度的問題，要求開立較長期支票，此時必須小心評估廠商情況。另外，如果廠商拖延不依約付款者，也要小心注意。
</dd>
<dd>
<p>至於請款，在合約簽定後，請依請款日期逕自案主的會計單位請款，如果有問題，再向案主反應，除非案主並無會計人員處理或已事先約定，不要一開始直接向案主請款，這會顯得不太禮貌。</p>
</dd>
<p></p></dl>
<p>
</p>
<h3><a name="2_2_4_____________q">2.2.4. 正式提案階段</a></h3>
<pre>
* 溝通內容：系統開發內容
* 溝通目標：配合報價，確認系統需求
* 溝通結果：正式合約</pre>
<p>與報價息息相關的是正式工作內容，因為對案主而言，工作內容決定接案者的報酬。對接案者而言，報酬決定了工作內容。通常到正式提案階段同時亦為簽約階段，你所揭的正式提案書常常是合約的附件之一，內容為雙方同意開發的系統功能，接案者是根據正式提案書所載明的系統功能內容進行開發工作，而未來的系統測試或驗收也是根據正式提案書所載的功能來進行。至於合約如何製定，我們會在另一章討論。這裡主要討論形成一份正式提案書的溝通事項。</p>
<dl>
<dt><strong><a name="item_附_a5醭a4_40_a1g_a5_bf_a6_a1_b4_a3_ae_d7_ae�">附件一：正式提案書</a></strong><br />
</dt>
<dd>
正式提案書記載的是實際要開發的各項功能，羅列的愈明確，對案主和接案者雙方保障也愈多，因此無論案主是否要求，都應主動將正式提案書列入合約中。
</dd>
<dd>
<p>正式提案書的內容除了系統功能之外，所有與專案開發相關的事件也須同步在正式提案書中進行規範，包括需求變更﹑驗收﹑保固以及後續維護的程序等，當合約簽訂之後，在系統開發過程中，雙方的互動均需按照正式提案書及合約所載來進行。</p>
</dd>
<dd>
<p>一般正式提案書所提到的重點有︰</p>
</dd>
<p></p>
<li></li>
前言／摘要：說明這個系統規劃的目的及目標，並摘要整個系統的各項功能。
<p></p>
<li></li>
介面功能規劃：先依主功能分項，再按介面動線描述該主功能項下的各細部功能。這是使用者所看到及所使用的功能。細部功能必須以字面描述的方式，詳盡到資料輸入及輸 出的結果。
<p></p>
<li></li>
管理系統功能規劃：所有介面功能背後都有相關的管理系統功能，此章節即在按系統功能項目分類，逐項描述各系統功能項下的細部功能。這是系統管理者所看到及所使用的 功能。細部功能必須以字面描述的方式，詳盡到資料輸入及輸出的結果。
<p></p>
<li></li>
系統架構規劃：說明開發本系統的軟、硬體規劃，如開發平台、相關程式語言、資料庫及整體系統架構的設計。
<p></p>
<li></li>
系統變更及處理原則︰規範系統開發過程中，如遇需求變更﹑介面功能修改等各項變更時的各項相關處理程序。
<p></p>
<li></li>
開發團隊：說明開發本系統所須花費的時間及人力及工作內容。
<p></p>
<li></li>
驗收程序︰規範系統驗收的程序以及驗收方式。
<p></p>
<li></li>
維護﹑保固及支援的相關辦法︰規範維護﹑保固以及支援的內容項目與時限。
<p></p>
<li></li>
附件二：系統開發時程規劃書
<p></p></dl>
<p>假設接案者已經預見到該專案在未來很可能將因各式各樣的原因而延遲，我們會建議將開發時程及交貨日期等項目獨立出來，在合約及正式提案書外，另簽訂一份系統開發時程規劃書。這本系統開發時程規劃書亦為合約的附件，視同合約，之所以不列在合約裡，為的是萬一雙方因需要必須修改開發時程，便可較容易依據現實狀況做修正而不需更動到合約。</p>
<p>系統開發時程規劃書可以載明各開發階段的工作內容﹑執行時間﹑雙方應配合交付的事項等，當階段性工作完成或目標達成時，案主需分期交付的價金也在此份時程規劃書內規範。簡而言之，系統開發時程規劃書內應包括︰</p>
<ul>
<li></li>
開發階段的劃分
<p></p>
<li></li>
各階段的時間劃分
<p></p>
<li></li>
各階段接案者的執行項目
<p></p>
<li></li>
各階段開始前案主應交付的資料
<p></p>
<li></li>
各階段結束時接案者應交付的成果
<p></p>
<li></li>
各階段結束後案主應交付的價金
<p></p></ul>
<dl>
<dt><strong><a name="item__a5hprototype_a8蜲嶱a7e_b2_7b_a8t_b2螵a5bb�">以Prototype具體呈現系統全貌</a></strong><br />
</dt>
<dd>
除了書面的正式提案書外，如果行有餘力，還可以用Prototype的方式將案主需求呈現給案主過目，讓案主可以實際操作整個系統使用者及管理介面，並藉由介面的操作來達成雙方對於系統的共識。透過Prototype的操作，案主也可以更清楚系統開發後的功能全貌。Prototype一旦經雙方認同之後，接案者即可根據Prototype來進行後端系統的開發工作。
</dd>
<p></p></dl>
<p>
</p>
<h2><a name="2_3___m___騶潷__q的___q">2.3. 專案執行階段的溝通</a></h2>
<p>好不容易，接案者與案主達成共識簽約。基本簽約以後的的溝通會比較輕鬆，畢竟合約是雙方的共識，有爭議時可以檢視合約解決。因此接案者此時的溝通目的是確保雙方會跟著合約走，防止意外的情形發生，順利結案。</p>
<p>基本上，整體專案執行流程可按階段性目標或所謂的里程碑（Milestone）分為幾個階段，每個階段內的溝通內容及溝通重點均有所不同，所要達成的共識也有所差異，若在每個溝通階段皆能掌握各個溝通要點，適當達成各溝通階段所應達成的溝通目標，將有助於專案開發的執行，並避免因認知不一致所導致的開發時程延誤或系統驗收無法完成等因溝通不良所衍生的各種問題。</p>
<p>專案執行階段的溝通內容及要點大致如下：</p>
<pre>
+------------+----------------------------------+----------------------------+
|專案執行階段|內容 |要點 |
+------------+----------------------------------+----------------------------+
|開發階段 |溝通內容：開發過程中雙方應相互配合|* 訂立系統規格書 |
| | 的事項 |* 站在案主的立場協助解決問題|
| |溝通目標：確認開發過程中雙方的權利|* 適當堅持原則 |
| | 義務 |* 記得修改系統開發時程規劃書|
| |溝通結果：修正後的開發時程規劃書或| |
| | 進行測試 | |
+------------+----------------------------------+----------------------------+
|測試驗收階段|溝通內容：測試驗收內容及方式 |* 以書面確認雙方均認同此測試|
| |溝通目標：同意測試驗收時程、內容及| 及驗收程序 |
| | 方式 |* 驗收報告書內需詳盡的羅列驗|
| |溝通結果：驗收報告書 | 收結果 |
| | |* 確認雙方均已在驗收報告書上|
| | | 簽字 |
+------------+----------------------------------+----------------------------+
|維護階段 |溝通內容：維護需求 |* 以書面確認維護的內容範圍、|
| |溝通目標：維護的時間及方式 | 保固期間以及維護價金 |
| |溝通結果：維護合約 | |
+------------+----------------------------------+----------------------------+</pre>
<p>
</p>
<h3><a name="2_3_1____發___q">2.3.1. 開發階段</a></h3>
<pre>
* 溝通內容：開發過程中雙方應相互配合的事項，決定是否訂立系統規格書
* 溝通目標：進度說明，確認開發過程中雙方的權利義務
* 溝通結果：修正後的開發時程規劃書或進行測試</pre>
<p>在開發階段時，所有與系統開發相關的細節均已大致底定，在正常狀況之下，開發過程應是順利並且按照開發時程規劃書所訂定的開發時程進行。這時溝通的重點除了定期聯絡告知案主開始進度外，另外應開始著手準備系統規格書，做為結案時說說明文件。另外，在開發過程之中常有一些不可預期的因素發生，讓開發時程一再順延，有可能是接案者在開發時遇到瓶頸，也有可能是案主變更需求或是延遲交付相關的資料而影響後續的開發工作。當遭遇到這些問題時，必須重新修正開發時程規劃書，以符合現實狀況，保障自身的權益。</p>
<dl>
<dt><strong><a name="item__adq_a5絻a8t_b2螵b3w_ae潷ae�">訂立系統規格書</a></strong><br />
</dt>
<dd>
當正式合約及正式提案書簽訂之後，接案者即可正式開始進行程式開發的工作。在一些大的專案中，接案者本身會製作系統規格書，主要目的是在程式開發之前，必須先訂定一些程式開發所須依循的準則，當作接案團隊內部的工作標準，減少接案團隊內部的溝通時間。另外，這裡頭的內容整理出來，最終會成為結案報告的一部份，在結案時一並交給客戶，供其日後進行程式維護時使用。
</dd>
<dd>
<p>在系統實際開發之前，必須先做好系統分析工作，以利後續的程式開發。好的系統分析可以有效率的開發系統，並確保系統開發結果符合實際使用者的需求。系統規格書的主要內容為系統分析的結果，包括︰</p>
</dd>
<ul>
<li></li>
資料的輸入及輸出結果︰包括欄位大小﹑屬性等細部資訊的定義。
<p></p>
<li></li>
系統執行時產生的訊息資料︰包括錯誤訊息﹑確認訊息以及出現這些訊息的前因後果等 細部執行細節的規範與定義。
<p></p>
<li></li>
資料的運作流程︰說明整個系統運作過程中，各種資料的流動及相關性。
<p></p>
<li></li>
功能的執行流程︰說明整個系統運作過程中，各項功能的運作流程及相關性。
<p></p>
<li></li>
DB Schema的設計︰定義整個資料庫的細節。
<p></p></ul>
<p>使用的工具可以包括︰</p>
<ul>
<li></li>
Context Diagram
<p></p>
<li></li>
資料流程圖（DFD）
<p></p>
<li></li>
實體—關係圖（ERD）
<p></p>
<li></li>
狀態—遞換圖（STD）
<p></p></ul>
<p>系統規格書主要在方便接案者進行整體系統的開發工作。由於整個專案可能過於龐大，而有不只一位的接案者參與開發工作，透過系統規格書的訂定，可以讓各個接案者了解整體系統的開發方式，並透過系統規格書裡所規範的開發細節，同步進行程式開發工作。此外，透過系統規格書的訂定，也可讓後續進來的程式開發者省卻大量與工作團隊面對面溝通詢問的時間，利用書面的溝通即可以最少的時間進入狀況。</p>
<p>接案者在進行專案開發前的系統分析工作時，可以順便將一些常用或一般系統必備的功能獨立出來設計開發，在未來再接案時，如果要需要類似的功能，便可以將這些已開發完成的功能拿出來再重覆使用，在初次開發時即將重用性納入考慮，如此將可避免未來重覆開發的問題。</p>
<dt><strong><a name="item__af_b8_a6b_ae_d7_a5d的_a5絻b3騶a8醭a7u_b8鎕a8m_b0�">站在案主的立場協助解決問題</a></strong><br />
</dt>
<dd>
在專案進行的過程之中，有時會牽涉到需要案主配合的部分，相關的規範雖已明訂於開發時程規劃書內，但有時案主因為自身的困難或其他原因，不一定能如期交付應配合項目，例如頁面或是相關資料庫連結的欄位及設定值等，造成後續專案工作無法進行，使接案者的時間受到拖延。這是接案者無法控制的局面，由於案主延遲交付的原因大多為沒有時間或是受到其他更重要的事情所拖累，建議可嘗試的解決方式有：
</dd>
<ul>
<li></li>
詳細列出需要案主提供的東西，最好提供選擇題的型式，讓案主選擇而非提出問答題讓案主花時間回答。舉例來說，如果需要案主提供會員資料庫的欄位及設定值，則可具體提出自己要求的欄位及設定值供案主決定好或不好，而不是讓案主自己提出欄位及設定值。
<p></p>
<li></li>
技巧性的探詢案主困難之所在，貼心的提供協助。
<p></p>
<li></li>
不要咄咄逼人，造成案主的不耐煩。
<p></p>
<li></li>
親自拜訪案主，讓案主花個會議的時間來解決或提供所需的資料。
<p></p>
<li></li>
親身站在案主的角度，體會案主的難處，並提供有限度的配合。
<p></p>
<li></li>
適度提醒案主，這樣的做法會造成完工時間的延遲。
<p></p>
<li></li>
平時在開發時，即與案主互有生活上或工作上的往來問候，建立除工作之外的情誼，較可避免拖延的狀況發生。
<p></p></ul>
<p>為避免開發時程受到案主或其他非可自身控制因素的影響，最好事先溝通清楚，並在訂定時程規劃書時，想辦法將需要案主配合的項目獨立出來，如遇案主拖欠應交付事項之時，便可先開發其他獨立的功能，待案主交付東西後，再回頭來開發相關的程式。</p>
<dt><strong><a name="item__bea_b7燲b0燲ab鸐ad餩abh">適當堅持原則</a></strong><br />
</dt>
<dd>
如遇案主提出需求變更要求時，應按照正式提案書內所規範的需求變更程序執行。先評估需求變更的影響，並根據評估結果決定是否接受變更要求。如果評估結果是不應變更，則應以委婉的態度以及書面的評估報告告知案主無法配合的原因，如果案主堅持變更，則告知勉強配合所會造成的後果，並由案主自行決定並負最後的責任。
</dd>
<dd>
<p>一切程序應按正式提案書以及合約規範來執行，任何在系統開發過程中所作的與合約或正式提案書不符的事件，均需以書面方式，由雙方簽名認可並留存備查，千萬不要因為嫌麻煩或是重人情而忽略一些執行上的細節，或是放棄原則盲目答應案主的所有要求。</p>
</dd>
<p></p>
<dt><strong><a name="item__b0o_b1o_ad_d7_a7駻a8t_b2螵b6_7d發_ae曀_7b_b3w_b9�">記得修改系統開發時程規劃書</a></strong><br />
</dt>
<dd>
不論是案主延遲交付應交付的事項或是案主於開發過程之中提出需求變更的要求，只要有影響系統開發時程，均須記得修改系統開發時程規劃書，以符合實際開發現狀。
</dd>
<p></p></dl>
<p>
</p>
<h3><a name="2_3_2___籓蓲____q">2.3.2. 測試驗收階段</a></h3>
<pre>
* 溝通內容：測試驗收內容及方式
* 溝通目標：雙方同意測試驗收時程、內容及方式
* 溝通結果：案主簽收驗收報告書</pre>
<p>當階段性功能完成時，雙方即可針對該功能進行測試工作並進行驗收。在進行測試及驗收之前，必須有一個雙方都認同的測試及驗收流程與方式，這個流程與方式即記載在測試及驗收說明書內。</p>
<dl>
<dt><strong><a name="item__a5h_ae鎕ad_b1_a4醂a6_a1_bdt_bb_7b">以書面方式確認</a></strong><br />
</dt>